mirror of
https://github.com/euzu/tuliprox.git
synced 2026-10-07 08:22:05 +02:00
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.