docs(riverctl): correct the v0.2.135 incident record, the announcement was not lost - #693
Merged
Merged
Conversation
…tion matters Three comments added by #688 say the multiplexing bug "broke the freenet v0.2.135 release announcement". It did not. The announcement posted. It is in the room, once, and a member replied to it half an hour later. The journal shows the send starting at 17:49:41Z, the message timestamped 17:49:43Z, and `FAILED with rc=1` at 17:49:54Z. That log line is `send_message_checked`'s, so the SEND is what reported failure and the script exited before reaching its convergence check. So the bug is a FALSE NEGATIVE: the update was transmitted, applied by the node and converged into room state, and riverctl reported it as a failure. The direction is the whole severity argument, which is why this is worth a commit rather than a footnote. It is the inverse of freenet-core#4318, where riverctl printed "Message sent successfully" while the contract silently dropped the delta and three announcements were lost. Every safeguard in `announce-to-river.sh` guards THAT direction. Nothing guards this one, and this one has its own hazard: a reported failure invites a retry, and a retry posts a duplicate release announcement to a public room. That retry was one command away, and was avoided only because the room was read back first. Filed as freenet-core#5640, which proposes the script run its existing convergence check before reporting a send failure. How the wrong claim got in: it was inherited from a handoff summary and carried through three review rounds without the room ever being checked. It was an inference from a script's exit code, and the exit code was the thing under investigation. Four reviewers read the code closely and none could have caught it, because it was never a claim about the code. No behaviour change; comments only. 385 tests pass, fmt clean. Claude-Session: https://claude.ai/code/session_015k3AmivdXMHWaZb8qGuQQz
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Three comments added by #688 say the response-multiplexing bug "broke the
freenet v0.2.135 release announcement". It did not. The announcement posted.
It is in the room, once, at 12:49:43 CDT, and a member replied to it 29 minutes
later. The journal gives the sequence:
FAILED with rc=1issend_message_checked's log, so the send reportedfailure and the script exited before reaching
verify_converged.So the bug is a false negative: the update was transmitted, applied by the
node, and converged into room state, and riverctl reported it as a failure.
Why this is worth its own PR rather than a footnote
The direction of the failure is the entire severity argument.
It is the inverse of freenet-core#4318, where riverctl printed "Message sent
successfully" while the room contract silently dropped the delta, losing the
v0.2.67/.68/.69 announcements. Every safeguard in
announce-to-river.shguardsthat direction, and its comments say so at length.
Nothing guards this direction, and it has its own hazard: a reported failure
invites a retry, and a retry posts a duplicate release announcement to a public
room. That retry was one command away here, and was avoided only because the
room was read back first. Filed as freenet-core#5640, which proposes the script
run its existing convergence check before reporting a send failure.
Leaving the wrong version in the source would mislead exactly the person most
likely to read it: someone hitting this again and deciding what it cost.
How the wrong claim got in
Inherited from a handoff summary and carried through three review rounds without
the room ever being checked. It was an inference from a script's exit code, and
the exit code was the thing under investigation. Four reviewers read the code
closely and none could have caught it, because it was never a claim about the
code.
The repo's own testing rules name this shape: a true artifact standing in for a
fact it does not establish.
announce-to-river.sh exited 1was true. "Theannouncement is missing" did not follow.
Approach
Comments only, no behaviour change. The three sites now say the announcement
reported a failure for a message that had already landed, and
await_response'sdoc carries the evidence and the direction argument.
Testing
385 tests pass,
cargo fmt --checkclean. No code changed.Related: #688, freenet-core#5640, freenet-core#4318.
https://claude.ai/code/session_015k3AmivdXMHWaZb8qGuQQz