Repository navigation
relay: a reply that never comes fails after its timeout, not the sync's - #50
Open
ChakraFusion wants to merge 1 commit into
Open
ChakraFusion wants to merge 1 commit into
ChakraFusion wants to merge 1 commit into
Conversation
exchange waited for the larger of wanRequestTimeout and the caller's own deadline. Every sync runs under a 30-minute per-peer deadline, so a manifest request or reply the relay dropped (it drops frames for a client that can't keep up, relay/server.go) held the sync for up to half an hour instead of failing it to be retried. It also made FetchBlocks' payload-sized deadline dead code: it applied only to a context without a deadline, which a sync never is. A request now waits wanRequestTimeout, or longer only when its caller asks with withReplyWait: block fetches for their payload as before, manifest requests for ServeSettleWait more, the time a peer may hold its answer while a sync writes the save. The caller's context still ends it early. Found as an e2e shard hitting the 30-minute limit on Windows CI, with TestThreeDevices_PerPeerStateStaysSeparate waiting 7m47s in one manifest fetch over the relay. Also: presence is written when it changes, not on every frame. trackPresence wrote the peer row (a synced database commit) for every frame a paired peer sent, block replies and heartbeats alike, on the one goroutine that reads the relay. A slow disk held that reading up, and the relay drops frames for a client that falls behind. The last-seen time is now written when something changed and otherwise every 5 seconds, as the LAN path does every 10; peers expire after 20. Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
@ChakraFusion is attempting to deploy a commit to the sivadaboi's projects Team on Vercel. A member of the Team first needs to authorize it. |
This was referenced Oct 14, 2026
This branch has not been deployed
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.
Found while chasing a CI timeout: an e2e shard hit the 30-minute limit on Windows, with
TestThreeDevices_PerPeerStateStaysSeparatestuck for 7m47s in one manifest fetch over the relay. The goroutine dump showed nothing serving that request on the other side, so the request or its reply had been dropped.exchangewaited for the larger ofwanRequestTimeoutand the caller's deadline. Every sync runs under a 30-minute per-peer deadline, so a request or reply the relay dropped (it drops frames for a client that can't keep up, by design) held the sync for up to half an hour instead of failing it to be retried. This also madeFetchBlocks' payload-sized deadline dead code: it only applied to a context without a deadline, which a sync never is.wanRequestTimeout, or longer only when the caller asks withwithReplyWait. Block fetches ask for their payload-sized time as before; manifest requests ask forServeSettleWaitmore (the time a peer may hold its answer while a sync writes the save). The caller's context still ends it early.trackPresencewrote the peer row (a synced database commit) for every frame from a paired peer, including each block reply and heartbeat, on the one goroutine that reads the relay. In the dump, two of the three daemons' relay readers were insideFlushFileBuffers. The last-seen time is now written when something changed, and otherwise every 5 s (the LAN path uses 10 s; peers expire after 20 s).Tests:
TestReplyWait_NotTheCallersWholeDeadline,…LongerWhenAskedFor, andTestTrackPresence_WritesOnlyWhenDue(fails without the change).🤖 Generated with Claude Code