Live output retarget is not safe against the producer thread (fleet-wide seqlock pattern)

[snokvist]

Summary

outgoing.server is live-settable. Applying it rewrites transport state on the HTTP thread while the encode thread is part-way through sending an access unit's datagrams. All three backends guard this with the same seqlock + per-frame snapshot — the encode thread copies the transport fields once per frame so every datagram of one frame goes to the same place.

Two gaps in that protection remain open. This is not a regression: the pattern in src/cv610_runtime.c is copied from src/star6e_output.c and src/maruko_output.c, so all three backends share it. CV610 simply made it reachable on a third platform, which is how it surfaced.

Filed to keep it visible rather than to block anything — every outcome below is a dropped or split access unit, not corruption.

Gap A — the snapshot does not cover the destination in the shipped default

connectedUdp: true is the default in all three configs. In that mode output_socket_send_parts() sets msg_name = NULL and the destination lives in the kernel socket, not in the snapshotted fields. A retarget changes it with connect() on the live fd.

So for a udp://a → udp://b retarget the snapshot protects nothing it was built to protect: one access unit can split across two receivers. Bounded — the bootstrap IDR that follows re-anchors the stream — and the misleading comments that claimed otherwise are corrected in #120.

Gap B — a live transport-type change closes and reopens the fd

output_socket_configure() closes and reopens when the transport type changes (udp:// ↔ unix://), while the encode thread still holds the old fd number in its snapshot. The reopen usually reclaims the same number, so a remaining sendmsg() for that frame can hit a socket of the wrong family, or EBADF in the gap. The send loop breaks on the first short send, so damage is bounded to a dropped access unit plus an output_drops increment.

Already fixed in #120

A third gap in the same area is closed: output_socket_configure() also closes the fd when destination fill fails with the type unchanged — reachable by setting a hostname URI, since nothing resolves names (inet_pton only). On a craft running a ring transport this was worse than a dropped frame: the value was committed and the daemon respawned into it, failed to bring output up, and stayed down until the config was repaired over ssh. The destination is now validated above both branches, before anything mutates.

Why the remaining two are not fixed here

The clean fix for Gap B is to route a live transport-type change to the restart class, reusing the pattern the ring branch already uses (commit the value, request a reinit, report reinit_pending). It is also the honest classification, since the fd genuinely cannot be swapped under a live producer.

Doing that on one backend changes observable API behaviour there and not on the other two: a client switching transport type would get reinit_pending: true and a respawn on one craft and a live change on another. That is a product decision about fleet consistency, not a bug fix, which is why it is an issue rather than a patch.

Options

1. Fix all three backends together — consistent, and the right end state. Largest change; touches the SigmaStar output paths.
2. Fix one backend now, accept the divergence — smallest change, but leaves the fleet inconsistent in behaviour on top of being inconsistent in correctness.
3. Leave as documented — current state. The gaps and what the seqlock does not cover are written into the transport_gen note.

Gap A is inherent to a live retarget and is probably not worth code in any option; it needs the destination to move into the snapshot, or connected UDP to be dropped for retargetable outputs.

Notes

An adversarial review of this area specifically tried and could not demonstrate a send landing in an unrelated subsystem's descriptor — the structural risk exists but has no live trigger, because nothing else allocates descriptors per-iteration while the HTTP thread is blocked in its own dispatch. Worth not overstating the severity when this is picked up.

The audio side channel was checked and is not affected: its apply path returns early when no socket is open and always derives a UDP type, so neither close path is reachable there.

[snokvist]

Partly addressed. The shared half is fixed and device-verified on both SigmaStar backends: output_socket_configure() no longer closes a working socket when the destination fill fails, and the call is now all-or-nothing.

That was the gap where a hostname URI took a live output down on every backend. Each bench was temporarily moved onto udp:// to reach the code (a craft on frame-shm:// refuses a live retarget before it), then restored:

Arm	Maruko	Star6E
good retarget udp→udp	ok, packetsSent 10372 → 11995	ok, 15170 → 16866
bad hostname URI	refused, config unchanged, packets 13659 → 14754	refused, config unchanged, 18504 → 19585
retarget again afterwards	ok	ok

Still open, and still a fleet decision — Gap A and Gap B above:

• Gap A (connectedUdp puts the destination in the kernel socket, outside the snapshot) is inherent to a live retarget and probably needs the destination moved into the snapshot rather than a patch.
• Gap B (a live transport-type change closes and reopens the fd) has a clean fix — route it to the restart class, as the ring branch already does — but that changes observable API behaviour, so doing it on one backend diverges it from the other two. That is the decision this issue exists to hold.

[snokvist]

Shared half landed in #122. What remains here is Gap A and Gap B only, and both are now scoped precisely:

Fixed and merged

• output_socket_configure() no longer closes a working socket when the destination fill fails — the call is all-or-nothing. Device-verified on Star6E and Maruko.
• A bad outgoing.server at boot no longer brings the craft down. The output comes up inert, transport/status reports active:false, and the operator recovers it live over the API. Verified end to end on all three backends. This was found while testing the above, and was the more severe failure of the two: no video and no API, recoverable only over ssh.
• The inert start re-seeds the transport policy the teardown clears, so a recovery cannot silently apply unconnected UDP or drop the Unix stall allowance.

Still open — and worth calibrating

Both remaining gaps are bounded to one dropped or split access unit, during a retarget the operator deliberately triggered:

• Gap A — connectedUdp puts the destination in the kernel socket, outside the seqlock snapshot, so a udp→udp retarget can split one access unit across two receivers. The bootstrap IDR re-anchors immediately. Fixing it means moving the destination into the snapshot or abandoning connected UDP for retargetable outputs; that is real cost for one frame, and it is probably not worth code.
• Gap B — a live transport-type change closes and reopens the fd under the producer. Clean fix exists (restart-class, as the ring branch already does) and it is the honest classification, since the fd genuinely cannot be swapped under a live producer. The blocker is not difficulty: doing it on one backend changes observable API behaviour there and not on the other two, and the seqlock is an inherited fleet-wide pattern rather than anything this work introduced.

So this issue is now holding a fleet-consistency decision, not outstanding work. The severe failure modes in this area are closed.