Repository navigation
quest: session policy lives in moq-net - #7885
Conversation
moq-tokio owns the accept and connect deadlines, admission bound, receive window widening and reconnect, and moq-relay's io_uring path hand-copies the server half. The new m1 epic moves that policy into moq-net as poll machines, points the io_uring path at it, and leaves moq-tokio a thin shell with the accept_with/connect_with handoffs the WebRTC rename (#7804) waits on. Folds in the poll-first server-machines quest and the m2 relay-serve-path quest. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- moq-relay's serve path is `Connection::run`, not `Connection::serve`. - moq-net already bounds the SETUP reply with `Handshake::with_deadline`; the accept deadline extends it back rather than adding a second one, and the caller still bounds the transport handshake. - The accept machine is `Server::accept_request`, which `accept` wraps. - uring.rs calls moq-net's `with_deadline`/`set_limits`; it copies the Deadline, admission bound and drain-bounded reply. - "Libraries spawn nothing" is #6849, not #7805. - moq-webrtc does not exist until the rename that requires the handoff, so the handoff's first consumer is moq-tokio's own webrtc module. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 8 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. |
There was a problem hiding this comment.
ℹ️ No critical issues — one low-stakes planning inconsistency inline.
Reviewed changes
- New m1 epic and four children —
quest/m1/session-policy/plans moving accept/connect deadlines, the admission bound, receive-window widening, and reconnect/backoff/GOAWAY into moq-net, withaccept.md,connect.md,uring.md, andtokio-handoff.mdas children. - Two quests folded in — deletes
quest/m2/relay-serve-path.mdandquest/m1/poll-first/server-machines.md, removes their list entries, and records the fold in the surviving quests with pinned "last version" links. - Dependency graph updated — links the epic from
quest/m1/README.md, makeswebrtc-rename.mdrequire the tokio handoff, removes the m2 README entry, and repoints the cut audit.
I checked the plans' symbol claims against the checkout: Server::accept_request/accept, Handshake::with_deadline/ok, transport::poll::Session::receive_window (no set_limits), tokio's Setup::deadline/within/Deadline/qmux_limits, the 30 s connect default, connection.rs's Backoff/Goaway/attempt_timeout/settles_walk/refreshed, relay Connection::run, uring::serve_request, Workers::bind, Lifecycle::shared, incoming::Sealed, and set_limits on tokio QUIC, qmux, and uring's web::Session. Every referenced quest file exists, neither deleted quest leaves a dangling relative link, and sh/markdown.sh check passes. I could not run quest check because no quest binary is on PATH in this environment.
deepseek-v4.1-flash-1017 (free via Pullfrog for OSS) | 𝕏
kixelated
left a comment
There was a problem hiding this comment.
Automated review by review (OpenAI)
Reviewed head de0b4e9 against base 3f39969. Moving shared session policy before the transport handoffs follows the recorded decision, but one prerequisite needs reconciling:
- P2: Move the SCTP-free gateway requirement out of the rename (webrtc-rename.md:13–15). The rename still requires WHIP/WHEP-only builds to skip SCTP, while the new decision defers SCTP removal to vendoring, which itself requires the rename. As documented in #7804, the pinned str0m dependency brings in
sctp-protounconditionally, so gating only the data-channel feature cannot satisfy the rename's retained requirement. Qualify that acceptance in the rename and explicitly carry the SCTP-free gateway build into the later vendoring work, preserving the decision to defer it.
Verification: GitHub-only static review of the plans, dependencies, originating diagnostic and current transport code, with independent passes. I did not run quest validation or build the feature matrix.
(Written by review (OpenAI))
The relay serve path proposal moved into m1, so it gets its own sentence instead of sitting in the list of work that can ship after the cut. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
- Cut-audit post-cut list corrected — the relay serve path entry is out of the "can ship after the cut" list, and a separate sentence records that it moved into m1 on 2026-11-04 as part of moving session policy into moq-net.
The new sentence reads coherently and its link resolves to quest/m1/session-policy/uring.md; sh/markdown.sh check passes.
deepseek-v4.1-flash-1017 (free via Pullfrog for OSS) | 𝕏

Problem
moq-dev/moq#7804 asked where moq-webrtc should plug its externally established transport in. Today moq-tokio owns all session policy: accept and connect deadlines, the admission bound, widening the receive window on admit, and reconnect with backoff and GOAWAY. moq-relay's io_uring path keeps a hand copy of the server half in
uring.rs, and eight commits so far have fixed drift between the copies. That policy runs onkio::clockand doesn't need tokio.Approach
A new m1 epic, Session policy lives in moq-net, with four children:
set_limitsontransport::poll::Session.Server::accept/Handshake::okbecome kio machines; this folds in the poll-first server-machines quest.uring.rs's copy; this folds in the m2 relay-serve-path quest. Requires 1.accept_with/connect_with. Requires 1 and 2.The WebRTC rename now requires child 4.
Decisions (maintainer, 2026-11-04, recorded in the epic):
Public API: none in this PR (plan only). Wire: none.
Validation
quest check --base origin/main --branch quest-plan/session-policy-moq-net(the flake's pinned quest): 616 documents ok. The olderquest0.1.0 on PATH rejects the## Waitingsections already on main.sh/markdown.sh check: passes.Review
Reviewer: Codex (
quest review), gpt-6.1-sol, medium effort, round 1, head de0b4e9: 0 findings.Before that round, a Claude Opus 5.5 pass checked the plan against the code at a5f5784 and fixed these in de0b4e9:
uring.mdnamedConnection::serve, carried over from the deleted quest; moq-relay's serve path isConnection::run(rs/moq-relay/src/connection.rs:84). Fixed.Handshake::with_deadline(rs/moq-net/src/server.rs:769), and uring.rs calls it instead of copying it. The README research,accept.mdanduring.mdnow say that the accept deadline extends this one back over SETUP and admission. The caller still bounds the transport handshake (within), sotokio-handoff.mdno longer listswithinfor deletion. Fixed.accept.mdnow namesServer::accept_request, the method moq-tokio and uring call;Server::acceptwraps it. Fixed.tokio-handoff.mdsaid moq-webrtc uses the handoffs, but moq-webrtc only exists after the WebRTC rename, which requires this quest. Its first consumer is now moq-tokio's ownwebrtcmodule, which the rename then moves. The epic's Goal says "the WebRTC transport". Fixed.The ✅ decisions were not reopened.
(Written by Claude Opus 5.5)
🤖 Generated with Claude Code