mirror of
https://github.com/euzu/tuliprox.git
synced 2026-10-28 17:52:50 +01:00
DarkBreakpoint
02480a4fc5
Task 12, step 2: "if capacity or source never becomes available before the padded end, the materialization becomes Failed without starting FFmpeg". This is the first test to run the real worker rather than the functions around it, which the capacity port made possible. It starts `ensure_recording_worker_running` against a provider that is permanently full and lets virtual time run past the broadcast. The worker asks for a slot, is refused, waits, and gives up when the programme it was going to record has finished. What is asserted is the whole outcome: Failed, with the stable reason, nothing recorded, no disk still reserved, one acquire attempt, and no release because it never held anything. Two notes for anyone writing more of these. A busy wait deadlocks a paused clock. The first version spun on `worker_running` with `yield_now`, which keeps the runtime runnable, so time never advances and the window never closes. It has to sleep. The test costs about 1.5s -- repository open and worker spawn, not the virtual sleep; trimming the sleep from 45 to 31 minutes changed nothing. That is enough extra load to tip `hls_cache_parallel_real_playbacks_same_virtual_id_register_distinct_streams`, which passes alone and under the full workspace run but failed when the DVR and app suites were run together. That test is timing-sensitive in the same way as the four availability tests; this did not make it fragile, only more likely to show it. Still not covered: ffmpeg started once at the padded start and stopped once at the padded end. That needs the source port -- something to stand in for ffmpeg itself -- which the capacity port does not provide.