GameCult/CultLib
Watch
9
0
Fork
You've already forked CultLib
 0
Code Issues Pull requests 4 Projects Releases Packages Wiki Activity Actions

cultmesh-ts: resend the capped frame's answer until acknowledged, then end the session #47

Merged
libby merged 1 commit from libby/ts-capped-answer-reliable into main 2026-11-08 10:59:28 +00:00
Conversation 0 Commits 1 Files changed 2 +110 -3
libby commented 2026-11-08 10:59:24 +00:00
Member
Copy link

Follow-up capped-answer-delivery-ts-rs-cs, TS; Python is fe73795d. endCappedSession deleted the session right after the capped (8th) frame's answer was sent, so the resend timer never saw it and a lost datagram left the peer without the answer. Now the session keeps running until the peer has acknowledged every reply (lost ones are resent) or a 2 s grace passes, then the goodbye goes out; frames behind the capped one are not served meanwhile. The resend timer ends it.

Touches no gate: write-authority decisions and the refusal frames are unchanged (the diff is endCappedSession, one early return in handleDocumentServerFrame, and the resend timer).

Tests (three new, with a UDP relay that drops server datagrams): a lost capped answer is resent and arrives before the goodbye; a never-acknowledged one still ends after the grace; nothing behind the cap is served. The first fails on main. Seven hand mutants under prlimit as=4GiB cpu=300, six applied cleanly and all killed (grace 0, grace 60 s, end without waiting on acks, end only at the deadline, remove the post-cap guard, end at once as before); the seventh pattern did not match. Suite: 186 pass; the one failure (content.test toNodeListener gzip) fails on main too.

🤖 Generated with Claude Code

Follow-up `capped-answer-delivery-ts-rs-cs`, TS; Python is fe73795d. `endCappedSession` deleted the session right after the capped (8th) frame's answer was sent, so the resend timer never saw it and a lost datagram left the peer without the answer. Now the session keeps running until the peer has acknowledged every reply (lost ones are resent) or a 2 s grace passes, then the goodbye goes out; frames behind the capped one are not served meanwhile. The resend timer ends it. Touches no gate: write-authority decisions and the refusal frames are unchanged (the diff is `endCappedSession`, one early return in `handleDocumentServerFrame`, and the resend timer). Tests (three new, with a UDP relay that drops server datagrams): a lost capped answer is resent and arrives before the goodbye; a never-acknowledged one still ends after the grace; nothing behind the cap is served. The first fails on main. Seven hand mutants under prlimit as=4GiB cpu=300, six applied cleanly and all killed (grace 0, grace 60 s, end without waiting on acks, end only at the deadline, remove the post-cap guard, end at once as before); the seventh pattern did not match. Suite: 186 pass; the one failure (content.test `toNodeListener` gzip) fails on main too. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
cultmesh-ts: resend the capped frame's answer until acknowledged, then end the session
Some checks failed
CultMesh QUIC native / Build win32-x64 (pull_request) Has been skipped
Details
CultMesh QUIC native / Build linux-x64 (pull_request) Has been skipped
Details
CultMesh QUIC native / Release native binaries (pull_request) Has been skipped
Details
CultMesh portability and performance / ubuntu-latest reactive semantics and leases (pull_request) Failing after 7m6s
Details
CultMesh QUIC native / Verify committed binaries match SHA256SUMS (pull_request) Successful in 51s
Details
9e5edeca52 
endCappedSession deleted the session right after the answer was sent, so the resend
timer never saw it and a lost datagram left the peer without the answer. The session
now stays until the peer has acknowledged every reply (a lost one is resent) or a 2 s
grace runs out, serves nothing after the capped frame meanwhile, and then sends the goodbye.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
libby merged commit 337168812e into main 2026-11-08 10:59:28 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
GameCult/CultLib!47
No description provided.