Repository navigation
Approve: register the trust pair before answering, and retry the answer - #53
Merged
Merged
Conversation
Approving a request told the registry about the new trust pair and sent the answer in parallel, once each, discarding every error. A private requester can't be looked up until the registry has the pair, so the direct accept usually failed; the relayed answer needs the registry's in-memory record of the request. When both copies were lost, the approver trusted the requester (one-way, with no key for a relayed request) while the requester still waited, and kept its messages queued: five hosted pairs had been stuck like this for up to three weeks. Now the pair is registered first, a relayed request's key is taken from the registry (backfillPeerKey), and the relayed and direct answers follow, each registry call retried (three tries, unless stopping; "no pending" is final), with a warning when the answer reached neither. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
TestOutgoing_CancelledRequestIsForgottenAcrossRestart never stopped the
manager it restarts from, so its background save could write trust.json
while the temp dir was being removed ("directory not empty"); it failed
30 of 30 runs under -race on main.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
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
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.
Why
Approving a friend request told the registry about the trust pair and sent the answer at the same moment, once each, discarding every error:
When both copies were lost, the approver trusted the requester one-way (and, for a relayed request, with no key) while the requester still waited and kept its messages queued. On the hosted fleet, five pairs were stuck like this, some for three weeks (repaired by hand on 2026-10-28; the hosted node now also re-sends its request when a message arrives from someone it asked).
What
ApproveHandshakenow, in the background:backfillPeerKey);retryRPC: three tries, a second then two apart, stops early when the manager is stopping.Tests
TestApproveRegistersThePairBeforeAnsweringAndRetries: order is report → key lookup → relay answer (first one dropped, retried) → direct accept, and the key is filled in.go test ./...passes.Not in this PR (separate, if wanted): the registry keeping pending requests across restarts (
rendezvoushandshake shard snapshot), and the daemon re-sending its request when a connection from a peer it asked is admitted only on the registry's word.🤖 Generated with Claude Code