Found during the #597 restart-floor investigation (sub-project 3, Task 7). Not fixed there — that task's scope was the restart floor, and this is a separate defect in how destinations are assigned to supervisors.
What happens
Each supervised sender creates a Destination record for every name in the sync list, not only the names it actually serves. So the SRT sender's supervisor also believes it supervises rtmp: it faults that destination forever, and restarts it against a child process that ignores the instruction entirely.
Evidence
In the incident logs this shows up as paired [outputSupervisor] restarting rtmp lines 6 to 10 ms apart — one from the supervisor that really owns the destination, one from a supervisor that does not.
Why it matters
It is harmless in the sense that the spurious restarts land on a child that ignores them. But it doubles restart traffic, and it makes the supervisor logs actively misleading during exactly the kind of incident you would be reading them to diagnose: a reader cannot tell which supervisor owns a destination, or whether a restart count is real or doubled.
The restart floor shipped in #597's sub-project 3 bounds how often a destination can be rebuilt, so this cannot produce a storm on its own. It should still be fixed before anyone relies on supervisor restart counts as evidence.
Done when
A supervisor creates a Destination record only for the names its own sender serves, and a log line naming a restart is unambiguous about which supervisor issued it. A test should pin that two senders sharing a sync list do not supervise each other's destinations.
Found during the #597 restart-floor investigation (sub-project 3, Task 7). Not fixed there — that task's scope was the restart floor, and this is a separate defect in how destinations are assigned to supervisors.
What happens
Each supervised sender creates a
Destinationrecord for every name in the sync list, not only the names it actually serves. So the SRT sender's supervisor also believes it supervisesrtmp: it faults that destination forever, and restarts it against a child process that ignores the instruction entirely.Evidence
In the incident logs this shows up as paired
[outputSupervisor] restarting rtmplines 6 to 10 ms apart — one from the supervisor that really owns the destination, one from a supervisor that does not.Why it matters
It is harmless in the sense that the spurious restarts land on a child that ignores them. But it doubles restart traffic, and it makes the supervisor logs actively misleading during exactly the kind of incident you would be reading them to diagnose: a reader cannot tell which supervisor owns a destination, or whether a restart count is real or doubled.
The restart floor shipped in #597's sub-project 3 bounds how often a destination can be rebuilt, so this cannot produce a storm on its own. It should still be fixed before anyone relies on supervisor restart counts as evidence.
Done when
A supervisor creates a
Destinationrecord only for the names its own sender serves, and a log line naming a restart is unambiguous about which supervisor issued it. A test should pin that two senders sharing a sync list do not supervise each other's destinations.