Files
pad/docs
xarmian 6ce542782d docs: say what each stream actually detects, not what the pair does (BUG-2730, codex round 6)
An end-to-end trace of a pub/sub flap found the deployment doc claiming,
for BOTH streams, that a reconnect or an undecodable message produces a
mid-stream sync_required. True of the activity bus, which subscribes with
ChannelWithSubscriptions and ends the workspace's coverage on either.
False of the watch bus, which uses a plain Channel() and discards an
undecodable payload with a log line — it learns of a hole only when a
later notification arrives non-contiguous, so a flap that loses the
newest notification with nothing published after it leaves a connected
CLI silently stale.

That gap is real and pre-existing (BUG-2731 was an activity-bus unit);
filed as BUG-2739 rather than folded in, because widening DETECTION is a
different claim from announcing what is already detected, and the watch
bus's single replay buffer makes "end coverage" a decision rather than a
copy. The doc now states the asymmetry and names the item.

Also from the same round, both mine: a comment in the activity fan-out
still said the drop was silent and that no bus had a channel to a live
consumer, three lines above the code that signals one; and two metric
descriptions still pointed operators at pad_*_resume_gaps_total for
mid-stream signals, which the previous commit deliberately moved to
pad_*_midstream_resyncs_total.
2026-08-23 01:08:43 +00:00
..