Keep the per-recipient code stream valid on failures after 64/65 - #36
Open
markmnl wants to merge 1 commit into
Open
Keep the per-recipient code stream valid on failures after 64/65#36markmnl wants to merge 1 commit into
markmnl wants to merge 1 commit into
Conversation
After responding code 64 or 65 the sender reads one byte per recipient, so per-recipient failure sites must write the per-recipient undisclosed code 105, not the header-level code 3 (SPEC SS8/SS10.4). Download or storage failures where the stream position is unknown now abort the connection instead of writing a header-level code into the stream; the sender records no response and retries. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.
Confirmed follow-up (b) of #33: after code 64/65 the sender reads exactly one byte per recipient it hosts, so any header-level code written at that point is consumed as a recipient's response code and desyncs the stream — the sender ends up recording global code 3 as a per-recipient outcome.
Changes
storeAcceptedMessage, payload copy failure, attachment persist failure) now write the per-recipient undisclosed code 105 instead of header-level code 3.downloadMessagefails inhandleConn— where the wire position within (or before) the per-recipient stream is unknown — the connection is now aborted instead of writing a header-level code 3 into the stream. The sender records no response (-1retryable sentinel) and retries later, per SPEC §10.4.🤖 Generated with Claude Code