DarkBreakpoint b854884202 feat(config): decide what a recording reload does, field by field ...

Task 13 step 2 asked for every recording setting to be classified as
live-applied, new-work-only, or restart-required. The design section it
pointed at was not available, so this is my classification; it is
written as a claim that can be checked rather than a preference.

The rule I used: a setting is only live-applied if every consumer reads
it from the current configuration at the moment it uses it. One consumer
holding a startup copy makes the claim false.

Applying that rule found a copy. `max_background_per_provider` and
`reserve_slots_for_users` were read from a `RecordingConfig` cloned into
the worker when it spawned, and again into the capacity bridge. A worker
outlives many reloads, so an operator raising the background limit saw
nothing happen until the queue drained -- and the same stale clone
decided which waiter got the next free slot. Both now load the live
config per attempt, which is what makes LiveApplied true rather than
aspirational.

The classification itself:

- restart-required is exactly one field, `notifications.outbox_buffer`,
  because it sizes an mpsc channel once at startup;
- new-work-only is the set baked into a recording when it is admitted --
  directory, filename template, container, padding, headers -- where the
  persisted record is authoritative from then on;
- everything else is live: capacity, retry, retention, disk and quota
  are all consulted inside loops that re-read config.

A reload is one decision over the whole block. There is deliberately no
outcome that applies some fields and rejects others: the root refusal
now rejects the entire replacement rather than quietly applying the
other twenty settings and keeping the old directory, which would leave
an operator running a configuration nobody wrote. Restart-bound fields
are still stored and are reported in the 200 so the change is known to
be pending rather than lost.

`RecordingField::ALL` plus a test that every field diffs on its own and
drags no neighbour along is what stops a new setting being added without
anyone deciding when it takes effect.

435 dvr, 300 core, 700 app pass.

2026-09-09 07:10:41 -05:00

..

src

feat(config): decide what a recording reload does, field by field

2026-09-09 07:10:41 -05:00

Cargo.toml

Feature/multi crate (#837)

2026-08-27 15:36:23 +02:00