feat(net): a token on a request authorizes that request

[ksletmoe-aws]

Implements quest/m1/auth/request-token, part A: an AUTHORIZATION TOKEN (0x03) on a request authorizes that request. Base is quest/m1/auth/README at 51c19e29d.

(Written by claude-opus-4.8)

Decisions applied

Reworked per your four answers and both automated reviews; the decisions are recorded in the quest Plan.

• Q1, credential home. The request token rides the auth handle beside session tokens, distinguished by kind: auth::Handle::set_request_token. No Client methods. Connection::auth() is not in the tree yet, so moq-tokio seeds the token from connect::Config::with_request_token on every (re)connected session; moq-tokio live renewal arrives with Connection::auth(), and renewal is available on moq-net's Session::auth() until then. Say if you want the handle built here instead.
• Q2, extensions. #[non_exhaustive] setup::Extensions { auth, solicit }, all on by default, via Client/Server::with_extensions, an extensions field on moq-tokio's connect::Config and listen::Config, and an extensions option on js/net connect/accept. It replaces both without_* methods and the private run_setup bools.
• Q3, client renewal. Kept: setting a new token on the handle re-presents it on every live request as a REQUEST_UPDATE.
• Q4. No EXPIRED / MALFORMED split; this PR answers UNAUTHORIZED and NOT_SUPPORTED, and the split lands with expired-error.

Review fixes, one commit each with a regression test:

• The announce filter and enforce_grant stand down only when the announce rides a PUBLISH_NAMESPACE (draft-14/15, or a peer that does not require Solicit); an inline NAMESPACE has no token slot, so the connection grant still bounds it.
• A token's grant is checked from the presenter's side (subscribe for SUBSCRIBE, publish for PUBLISH_NAMESPACE), initially and on renewal, and an Issued::update that stops covering the request ends it.
• The local limit (Handle::authorize) bounds the token path in both directions, including a later narrowing.
• A renewal keeps the subscription's range (token-only on draft-15+; draft-14 restates the start), and a stream closed during a pending renewal ends the request.
• A reprice carries no token, so HOP_PATH / ROUTE_COST are not dropped; renewals before draft-17 are decided without an answer; token bytes never reach Debug output.
• MAX_REQUEST_UPDATES is advertised and enforced (see below), replacing the earlier hidden buffer cap.

What it does

A request is authorized by the session's grant first; when that does not cover it, by the token on the request; with neither, UNAUTHORIZED. The token's grant covers only its request, never joins the session union, and ends with the request. A REQUEST_UPDATE with a new token replaces the grant and its expiry; a refused one keeps the old grant until it lapses; a lapse or acceptor revoke ends only that request, never the session. An alias or DELETE form token closes the session PROTOCOL_VIOLATION, as at SETUP. With no requests() consumer a non-empty token is refused Unsupported, so an app that does not opt in is unchanged, and a token-less peer is byte-identical on the wire.

The number of unacknowledged REQUEST_UPDATEs a peer may leave on one request stream is bounded. On the drafts that define it (19+) that bound is advertised as the MAX_REQUEST_UPDATES Setup Option, counting the one being verified; a peer that exceeds the advertised value is closed with TOO_MANY_REQUEST_UPDATES, which is the consequence draft-19 section 10.3.1.7 prescribes. Every REQUEST_UPDATE is answered, token or not, so its credit is restored (section 10.9). Drafts below 19 carry no such option, so a peer there agreed to no ceiling: they keep a generous local guard that ends only the one request, never the session.

The sender honors the same bound without reading it: a subscription keeps at most one renewal in flight and coalesces replacements that arrive behind it, sending the newest once the outstanding one is answered. The announce update path was already one-at-a-time per stream. The peer's advertised limit is recorded from SETUP (an absent option or a 0 both meaning no limit) for a future sender that paces to it exactly.

• Decode reuses the SETUP option's Token structure (section 8.9 rules) in both decoder families. fix(ietf): decode every legal request and refuse per request #4610 already ignores unknown keys, so the decode-only accepts on FETCH / PUBLISH / TRACK_STATUS / SUBSCRIBE_NAMESPACE are explicitness; happy to drop them.
• An uncovered request's token becomes an auth::Request on the session's handle, tagged with path and kind, regardless of the Auth extension. The token path is entered only when the union does not cover the path, so the token-less fan-out path is untouched.
• moq_tokio::server::Request::auth() exposes the handle before ok(), so a QUIC server installs its consumer before the driver's first poll.
• js/net decodes and drops 0x03 on every request message.

A lapsed announce grant ends the PUBLISH_NAMESPACE request and blocks new subscribers, but established subscriptions keep flowing; "a lapsed grant stops media" is the subscribe-side property.

Public API and wire impact

Wire: the MAX_REQUEST_UPDATES Setup Option (type 0x08) is advertised on the drafts that define it (19+), and TOO_MANY_REQUEST_UPDATES (code 0x1B) closes the session when a peer exceeds it. The 0x03 request parameter is otherwise defined in every supported draft (draft-17 9.3.2 / draft-18+ 10.2.2; Token structure 8.9 / draft-21 9.1.4; REQUEST_UPDATE draft-17 9.10 / draft-18+ 10.9).

moq-net, additive over the base: auth::RequestKind; auth::Request::{path, kind, token_kind}; auth::Handle::set_request_token; SessionError::TooManyRequestUpdates; setup::Extensions; Client::with_extensions, Server::with_extensions. moq-tokio: connect::Config::{extensions, with_request_token}, listen::Config::extensions, server::Request::auth(). js/net: extensions on ConnectProps / AcceptProps. The machinery and the ietf message types are crate-private.

Verification

fmt, clippy -D warnings, nextest (moq-net lib 1457, --test auth 82, moq-tokio lib 246), wasm clippy, cargo doc -D warnings, shear, sort, just js check, bun 1103. Renewal is proven over the wire through both drivers at draft-18 (a_request_token_renews_a_subscription_through_the_driver). The negotiated-limit boundary is covered on both the publisher and subscriber: exactly the limit succeeds, one past closes the session with TOO_MANY_REQUEST_UPDATES, and the older-draft guard ends only the request. A two-driver held-verifier test (a_held_renewal_coalesces_a_burst_without_tripping_the_credit) confirms the sender stays within the credit: with the first renewal's verifier held, a burst of token replacements well past the credit keeps the session up and resolving the verifier releases exactly the newest token. Also exercised against a downstream relay built on moq-net over real QUIC with the token seeded on the dial config: token-authorized SUBSCRIBE and PUBLISH_NAMESPACE, lapse ending only the request, alias token closing the session, no-consumer refusal.

Follow-ups (out of scope here)

• JS: an outgoing-token setter and an accept-side requests() equivalent, as one follow-up; the quest scopes js/net to decode plus default refusal.
• moq-cli --request-token knob (raw Token bytes vs a JWT to wrap is a semantic choice).
• Part B: the relay's per-request moq_auth::Client lease, which needs relay-refresh's Client::attach.
• A REQUEST_UPDATE token on a request the session grant already covers is ignored; attaching a request grant there is possible but we lean no.

Commits carry a Co-Authored-By: Claude trailer.

[kixelated]

Solid request-token vertical: covers vs allows is wired correctly (None union does not admit a token-bearing request; token-less stays permissive), alias DELETE/USE_ALIAS closes the session as ProtocolViolation, and renewal races the verify against RequestGrant::poll_ended so a slow acceptor cannot outlive the old deadline. Reviewed head 928d4a52f30b063e9c73a9158f77bd777d58c936.

Blocking

1. Announce self-censor / enforce_grant stand down even when Solicit means the token cannot ride (publisher.rs:1676, session.rs:1092; subscriber subscribe gate at subscriber.rs:1854 is fine because SUBSCRIBE always carries the token).
   • When request_token is set, permitted becomes always-true and dialing-side enforce_grant returns immediately. That is correct for an unsolicited PUBLISH_NAMESPACE (token on the wire; server covers + acceptor are the authority).
   • Under default Solicit, the client answers SUBSCRIBE_NAMESPACE with inline NAMESPACE, which has no token slot (integration test at tests/auth.rs even asserts the acceptor is never consulted). The stand-down still applies, so a client that set a request token for SUBSCRIBE (or for a without_solicit ingest path) can advertise paths outside its connection grant with no request-token verify on the server.
   • Failure scenario: AUTH connection grant is room/alice/*, client also with_request_token(...), peer declared Solicit, origin has room/bob/cam → NAMESPACE advertises room/bob/cam with no token; server attach only applies within_limit / origin scope, not a per-request token check.
   • Suggested fix: stand down announce self-censor / enforce_grant only when the announce will actually carry the token (peer solicit is false/None, or this session used without_solicit); keep filtering when Solicit forces the inline NAMESPACE path. Alternatively, enforce the peer's publish grant on NAMESPACE receive when no request token was verified.

Non-blocking

2. Known follow-up, still a real cluster bug: PUBLISH_NAMESPACE_UPDATE with a token on a token-authorized announce renews and continues before cluster apply (subscriber.rs:1311-1342), while the sender always attaches the current request token on every reprice (publisher.rs:1897). So for token-authorized cluster announces, reprices that also refresh the token silently drop HOP_PATH / ROUTE_COST even though the sender got REQUEST_OK. Apply cluster params after (or alongside) renewal, or omit an unchanged token from reprice-only updates.

3. Draft-14/15/16 renewal answers are misrouted by the control-stream adapter. Publisher writes RequestOk / SubscribeError/RequestError with the update's Request ID on the virtual subscribe stream (publisher.rs:840, :846). The peer adapter classifies 0x05 as CloseStream(id) and draft-15/16 RequestOk as Response(id) (adapter.rs:920-925, :949-957) — but the update id was never registered (SUBSCRIBE_UPDATE is FollowUp to the subscription). Answers never reach read_publish_done. Draft-17+ real streams are fine; draft-14 accept is intentionally silent. Media still works (client does not require the answer), but moq-net↔moq-net on 15/16 never observes renewal OK/ERROR. Prefer FollowUp-to-subscription routing for those answers, or document silence on 14–16.

4. Token bytes can land in logs. PublishNamespace / PublishNamespaceUpdate / related msgs #[derive(Debug)] include authorization_token: Option<Bytes>, and several paths log message = ?msg (e.g. publisher.rs:2089, subscriber.rs:2253, and inbound received publish_namespace). Prefer logging only kind/length/path, not the credential bytes.

5. CI: Android and Release JS Packages have passed; Check / Test / WASM / macOS / Windows were still pending at review time — re-check before merge.

Verdict

ITERATE

This is an automated review, not the maintainer's decision
(Written by Grok)

[kixelated]

Automated review by review (OpenAI)

Reviewed commit: 928d4a52f30b063e9c73a9158f77bd777d58c936

Reusing the acceptor is a sensible direction, but the authorization boundaries and renewal lifecycle need the five fixes below. A shared request guard owning presenter-facing scope, local ceiling, grant updates and cancellation would simplify the duplicated state machines.

I also independently confirmed the mixed cluster/token-update and legacy renewal-response routing issues in the existing review comment, so have not duplicated them inline.

Verification: static review of the exact-head diff, surrounding call paths and IETF update rules. No builds or tests were run.

[kixelated]

[P1] Check request grants from the presenter's perspective

Request::accept grants the presenting peer's permissions: ietf/auth.rs:482–485 sends its fields unchanged as AuthOk. An incoming SUBSCRIBE therefore needs grant.subscribe, not grant.publish. On a no-AUTH session, a publish-only credential currently gains read access, while a subscribe-only credential is refused. PUBLISH_NAMESPACE checks the inverse wrong field at subscriber.rs:1118. Correct both initial and renewal checks, and add asymmetric read-only/write-only grant tests.

[kixelated]

[P1] Preserve the local authorization ceiling on the token path

With an origin serving room, call auth.authorize(Grant::default()), then accept a request token with Grant::all(): this branch still serves the SUBSCRIBE and leaves gate unset. A later local narrowing also cannot stop it. The received union and the local limit are separate (auth.rs:178–187); a request token may replace the former, not bypass the latter. Keep within_limit checks and limit-change monitoring independently. The outgoing token-based permitted/Gate bypasses need the same separation.

[kixelated]

[P1] Recheck request coverage after an Issued grant update

After accepting a token-authorized subscription or namespace with Grant::all(), calling issued.update(Grant::default()) should remove its access. Here the replacement only updates the stored grant/deadline; neither caller rechecks the new patterns. Because the empty grant has no expiry, poll_ended remains pending and the request continues indefinitely. Retain the request path and required permission in this guard and end it whenever a replacement no longer covers them.

[kixelated]

[P2] Preserve the subscription range when refreshing its token

These zero locations are not a token-only update. On draft-14, a live SUBSCRIBE with Largest Object {10,5} starts at {10,6}; renewal resets it to {0,0}, decreasing the start and requiring a peer to close the session with PROTOCOL_VIOLATION (draft-14 §9.10). On newer drafts, SubscribeUpdate::encode_msg always sends Filter::NextObject, replacing an absolute/ranged filter. Preserve the established range on draft-14 and omit unchanged filter/forward/priority parameters where the draft permits.

[kixelated]

[P2] Observe request cancellation while renewal verification is pending

Accept a PUBLISH_NAMESPACE with a non-expiring grant, send a renewal, leave its verifier pending, then FIN/reset the request stream. This wait polls only the old grant and new verdict, so the route stays attached indefinitely and the original Issued::closed() never resolves. The subscribe renewal wait has the same omission (publisher.rs:768–789). Race verification against request-stream closure too; an expiry deadline does not bound this when expires is None.

[kixelated]

Maintainer decisions on the four questions:

Q1. Request-token credential: ✅ Option 3, through Connection::auth() alongside session tokens, distinguished by kind. No Client::with_request_token / set_request_token.

Q2. Declining Auth and Solicit: ✅ a positive extensions declaration instead of without_* methods: a #[non_exhaustive] Extensions { auth: bool, solicit: bool } (Default = all on) on moq-net's client/server config, mirrored on moq-tokio's dial and listen Config (and JS). It replaces without_auth_extension / without_solicit and folds in the private run_setup bools; later extensions join the same struct.

Q3. Client-side live renewal: ✅ keep it in this PR, via the auth() handle: changing the request token there re-presents it on live requests (SUBSCRIBE_UPDATE / PUBLISH_NAMESPACE_UPDATE).

Q4. EXPIRED / MALFORMED_AUTH_TOKEN: ✅ later, with the expired-error quest. Keep UNAUTHORIZED / NOT_SUPPORTED here.

Please record these in the quest Plan when you rework. Thanks!

(Written by Claude Opus 5.5)

[ksletmoe-aws]

Reworked per your four answers and the review; history rewritten, head c6c4530. (Written by claude-opus-4.8)

[kixelated]

Automated review by review (OpenAI)

Reviewed commit: c6c4530701fdabacc1854693480099508e842c70 (reworked delta from 928d4a5; both share base 51c19e2).

The presenter-facing grant checks, local ceilings, Issued::update coverage, renewal range, solicited-namespace filtering and request-message redaction are addressed. Two P2 findings are inline.

Two previous findings are only partly fixed, so I have not duplicated them inline:

• Pending-renewal cancellation: publisher.rs:831–835 buffers a legacy UNSUBSCRIBE and then stops reading; the adapter delivers that terminal message before EOF. With a pending verifier and non-expiring grant, cancellation still hangs. Both renewal loops also miss closure after buffering another update (subscriber.rs:1240–1253). Keep terminal detection active and cover draft-14/15/16 cancellation.
• Mixed token/cluster updates: this sender now separates them, but subscriber.rs:1348–1379 still discards a peer's HOP_PATH/ROUTE_COST when renewing. Apply both parts before acknowledging.

Direction: the shared auth handle and positive extension config are improvements. A shared cancellable renewal state would simplify the remaining duplicated lifecycle logic. The moq-tokio live-renewal deferral still needs agreement before Q1/Q3 are considered complete.

Verification: static review of pinned old/new source, surrounding paths, tests and draft rules. No builds/tests run; CI remains queued/running (Android passed).

[kixelated]

[P2] Keep required renewal responses on draft-15/16

Unlike draft-14, draft-15 §9.11 and draft-16 §9.11 require one REQUEST_OK or REQUEST_ERROR per update. This condition now silently accepts or refuses a valid renewal, leaving an external peer waiting for its result. Restrict silence to draft-14 and fix the adapter's update-ID response routing instead of suppressing the wire response.

[kixelated]

[P2] Gate incoming AUTH on the server's offer too

With extensions.auth = false, a client can still advertise Auth and send AUTH: ietf/session.rs:442 supplies Some(serve), and :896–899 checks only the peer's offer. auth::Serve::run then grants the empty token or invokes the app verifier despite this handle being unsupported. The Auth draft's Setup Negotiation requires both offers and a PROTOCOL_VIOLATION for AUTH otherwise. Disable inbound serving when the local offer is off and test this asymmetric handshake, as JS already does.

[ksletmoe-aws]

Pushed five fixes for the second review round and the Check failure (c6c453070..8c9a8564a), one commit each with a regression test:

• Check dead-code: the client request token field is gated to the transport feature that reads it, so it is live in every feature build (moq-tokio).
• Pre-draft-17 renewal answer: a subscribe renewal is now answered on draft-15 and draft-16, one REQUEST_OK or REQUEST_ERROR keyed to the update, and silent only on draft-14.
• Declined Auth: a server that declines the Auth extension refuses an inbound AUTH stream as a protocol violation instead of serving a request it never offered.
• Pending-renewal cancellation: both renewal loops keep reading while a verdict is pending, so a cancellation ends the request on every draft (before draft-17 it is a message, not a stream close) and a buffered later update no longer masks it.
• Mixed update: a REQUEST_UPDATE carrying both a token and HOP_PATH / ROUTE_COST applies the routing as well as the renewal, with one answer.

On cancellation I kept the subscribe and publish-namespace loops as two shapes rather than a shared cancellable state: their terminal predicates and buffered-message handling differ enough that unifying them would be forced. Happy to unify if you would prefer it.

CI: the Check failure was the dead-code above. If the Test / WASM jobs come back red on the Nix cache fetch (HTTP 416), that is the same infra flake as before, not these changes.

One open question (moq-tokio live renewal). Connection::auth() is still not in the tree, so moq-tokio seeds the request token from connect::Config::with_request_token on every (re)connected session, and live renewal is reachable on moq-net's Session::auth() until then. Three ways to close it:

1. As pushed: keep the config seed; moq-tokio live renewal arrives with Connection::auth() when that lands. (Recommended: no new surface, and the renewal path is already proven on moq-net.)
2. Build a minimal Connection::auth() now, so moq-tokio gets live renewal in this PR.
3. A temporary Client::set_request_token shim (you asked for no Client methods, so listed only for completeness).

(Written by claude-opus-4.8)

[kixelated]

Automated review by review (OpenAI)

Reviewed 8c9a8564a92a3e891dd28b04c493d00d4792d75d, the five-commit delta from c6c4530701fdabacc1854693480099508e842c70 on the same base.

The local AUTH-off gate, cancellation detection, and mixed token/cluster application are addressed. Draft-15/16 renewal replies are now emitted, but their round trip remains incomplete.

• P2: preserve buffered wire updates, not just the latest message. subscriber.rs:1267-1271 and publisher.rs:890-893 overwrite an earlier buffered update while verification is pending. With renewal A pending, B changing HOP_PATH followed by C changing only ROUTE_COST loses B's path and response. Multiple token renewals similarly lose an intermediate verdict/response. Updates are sparse deltas; draft-18 §10.9.1 permits cumulative coalescing but still requires each successful update's acknowledgment. Preserve those semantics while watching cancellation, and test two buffered updates followed by a resolved verdict.

Remaining existing behavior, not new findings from this delta:

• The previous adapter-routing issue remains: subscriber.rs:2411-2430 sends a new update ID, but adapter.rs:347-355 registers only the initial request. Replies keyed to the update still have no destination.
• Refused renewals still keep the old request alive (publisher.rs:922-933, subscriber.rs:1285-1290). That policy needs reconciliation with draft-16 §9.11.1 and draft-18 §10.9.1, which require failed updates to terminate the subscription/namespace request.

Direction: the fixes improve the auth-handle design; keep explicit per-update state and responses while detecting cancellation in both renewal loops. The declared moq-tokio live-renewal deferral remains a maintainer decision. Verification was static source/diff, test inspection and draft comparison. No builds/tests run; Check, WASM and Platform were still in progress when inspected.

(Written by OpenAI Codex)

[ksletmoe-aws]

Pushed c51dd1855 addressing the latest review.

Buffered REQUEST_UPDATEs (publisher.rs, subscriber.rs): both renewal loops now keep a bounded FIFO of the updates buffered while a verdict is pending and drain it in order, so each update is verified and answered and each cluster delta applied; the bound (draft-19 MAX_REQUEST_UPDATES) ends the request, not the session, if a peer floods behind a slow verdict.

Pre-draft-17 renewal reply routing (adapter.rs): the control-stream adapter now records a SUBSCRIBE_UPDATE's own Request ID against the subscription it renews and routes the REQUEST_OK / REQUEST_ERROR (keyed to the update id on draft-15/16) back to that subscription stream as data, so a draft-15/16 client observes the answer and a refused renewal keeps the subscription open.

Refused-renewal policy (your call). You flagged that keeping the old grant on a refused renewal conflicts with the drafts. Checking the texts (verified against draft-17 and draft-18; the rule is unchanged across them and the review cited the draft-16 section 9.11.1 equivalent):

• draft-17 section 9.10.1 / draft-18 section 10.9.1: "The receiver of a REQUEST_UPDATE MUST respond with exactly one REQUEST_OK or REQUEST_ERROR," and "When a [subscription] update is unsuccessful, the publisher MUST also terminate the subscription with PUBLISH_DONE with error code UPDATE_FAILED"; draft-18 adds that for a SUBSCRIBE_NAMESPACE or PUBLISH_NAMESPACE the responder MUST close the bidi stream.

So the drafts do require a failed update to terminate the request; the quest's "leave the old grant until it lapses" is a deliberate deviation. Three ways to reconcile:

1. Follow the drafts (my recommendation): a refused renewal ends that request with the REQUEST_ERROR, the session stays up. Spec-conformant and the more conservative posture (a revoked credential drops its request promptly rather than lingering), and the never-close-the-session property holds either way.
2. Keep the quest rule as implemented and amend the quest text to record the deliberate deviation.
3. Make it configurable (listed for completeness; likely over-engineering).

The code is on the current keep-old-grant behavior pending your decision; (1) is a small change.

Still open from the earlier comment: whether the client wrapper should carry live request-token renewal now, or wait for the Connection::auth() reconnect handle (today it seeds from connect::Config and renews on Session::auth()).

(Written by claude-opus-4.8)

[kixelated]

Automated review by review (OpenAI)

Reviewed c51dd18555356039dd61d98ecd4690636c189e76, the delta from 8c9a8564 on the same base.

The FIFO fixes the lost buffered updates and sparse cluster deltas within its limit. The draft-15/16 update-ID mapping now routes renewal replies to the real subscriber reader; the previous reply-routing finding is addressed.

• P2: advertise a renewal limit before enforcing it. publisher.rs:901–906 and subscriber.rs:1282–1286 terminate the request once one verification is pending and 16 further updates are queued. However, SETUP:665–681 advertises no MAX_REQUEST_UPDATES. Draft-19 §10.3.1.7 defines omission as zero/unlimited, so a conforming peer can send the next update and unexpectedly lose its subscription or namespace while the verifier is slow; cluster-only reprices behind one token renewal are sufficient. Advertise and enforce consistent finite credit on versions supporting that option, including the in-flight verification in the count, and use a version-appropriate bounded strategy for older drafts. Add a negotiated-limit boundary case; the current flood tests only assert termination.

Direction: preserving per-update state and routing legacy replies are improvements. The existing failed-renewal policy still conflicts with the drafts and remains an explicit maintainer decision, as does moq-tokio live renewal; these are not new findings.

Verification: exact-head source/diff, surrounding SETUP/adapter/subscriber paths, tests and primary draft text. No builds/tests run locally. Android reported success; Check, WASM and Platform were still running when inspected.

(Written by OpenAI Codex)

[ksletmoe-aws]

This round advertises and enforces MAX_REQUEST_UPDATES: a finite credit on the drafts that define it (19+), the draft-prescribed TOO_MANY_REQUEST_UPDATES close on a peer that leaves one more outstanding than that, a version-appropriate local guard below 19, and every REQUEST_UPDATE now answered so its credit is restored. Boundary-tested on both the publisher and subscriber (exactly the limit succeeds, one past closes the session).

Rounds 1-4 so far

• The grant-bypass blocker: the announce filter and the dialing-side grant stand down only when the announce actually carries a token, so an inline NAMESPACE stays bounded by the connection grant.
• A session that declines the Auth extension refuses an inbound AUTH stream rather than accepting it.
• Pre-draft-17 renewals are answered and routed back to the request that sent them.
• A request is cancellable while its verify is still pending; a renewal keeps the subscription range; a mixed token and cluster update applies both and answers once.
• Token bytes stay out of Debug output; buffered renewals are each answered, not collapsed.
• This round: advertised and enforced MAX_REQUEST_UPDATES.

Open for your call

• Refused-renewal policy: draft-16 section 9.11.1 and draft-18 section 10.9.1 require a failed update to terminate the request; the quest keeps the old grant until it lapses. Recommendation: follow the drafts. Options in feat(net): a token on a request authorizes that request #4675 (comment).
• moq-tokio live renewal: seed the token from connect::Config now, versus building a Connection::auth() handle in this PR. Recommendation: seed now. Options in feat(net): a token on a request authorizes that request #4675 (comment).

We will hold further rounds for those two rulings unless a review surfaces a correctness issue inside the current design.

(Written by claude-opus-4.8)

[kixelated]

Automated review by review (OpenAI)

Reviewed fe264a0339e334d8a52274267e989f8726efb7a9, the one-commit delta from c51dd185 on the same base.

The draft-19+ receiver now advertises the same 16-update credit it enforces, counts the pending verification, and acknowledges tokenless updates. Those parts of the previous finding are addressed. On older drafts the unadvertised guard is raised to 64 queued updates; the same request-termination behavior remains beyond that threshold.

• P2: make the outgoing subscriber honor update credit before enforcing it session-wide. The new publisher.rs:914-919 closes the entire session on the 17th outstanding renewal, but SETUP parsing:632-638 drops the peer's limit, and subscriber.rs:2245-2274 sends each observed token change without waiting for a response. Its response reader only logs acknowledgments. Between two copies of this implementation, hold the first renewal's verifier and make 17 distinct token replacements, allowing the driver to send each: an application using the public auth handle now loses every request on the connection. Draft-19 §10.3.1.7 requires the sender to respect this credit. Either track the peer's per-stream allowance and restore it on responses, or keep one renewal in flight and coalesce unsent replacements. Add a two-driver test with a held verifier and verify that resolving it releases the next renewal without disconnecting.

Direction: the advertised receiver bound is an improvement, but the sending half needs to participate in the contract. The existing refused-renewal policy and moq-tokio live-renewal decisions remain open; I have not repeated them as new findings.

Verification: pinned delta and surrounding SETUP, sender, receiver, response and test code, plus primary draft text. No Rust builds or tests run locally; the returned CI workflows were still running when inspected.

(Written by OpenAI Codex)

[ksletmoe-aws]

This round makes the sender honor the update credit it was already advertising: a subscription keeps at most one request-token renewal (REQUEST_UPDATE) in flight at a time and coalesces replacements that arrive while one is unanswered, so the newest token is sent once the outstanding one is answered. It stays within any MAX_REQUEST_UPDATES a peer advertises (draft-19 section 10.3.1.7) without reading it, and the peer's advertised limit is now recorded from SETUP for a future sender. A two-driver test with a held verifier covers it: a burst of token replacements well past the credit behind one held renewal, the session stays up, and resolving the verifier releases exactly the newest token.

Rounds 1-5 so far

• The grant-bypass blocker: the announce filter and the dialing-side grant stand down only when the announce actually carries a token, so an inline NAMESPACE stays bounded by the connection grant.
• A session that declines the Auth extension refuses an inbound AUTH stream rather than accepting it.
• Pre-draft-17 renewals are answered and routed back to the request that sent them.
• A request is cancellable while its verify is still pending; a renewal keeps the subscription range; a mixed token and cluster update applies both and answers once.
• Token bytes stay out of Debug output; buffered renewals are each answered, not collapsed.
• Advertised and enforced MAX_REQUEST_UPDATES: a finite credit on the drafts that define it, the draft-prescribed TOO_MANY_REQUEST_UPDATES close on a peer that leaves one more outstanding than that, a local guard below 19.
• This round: the sender keeps one renewal in flight per request and coalesces to the newest, and the peer's advertised limit is recorded from SETUP.

Open for your call

• Refused-renewal policy: draft-16 section 9.11.1 and draft-18 section 10.9.1 require a failed update to terminate the request; the quest keeps the old grant until it lapses. Recommendation: follow the drafts. Options in feat(net): a token on a request authorizes that request #4675 (comment).
• moq-tokio live renewal: seed the token from connect::Config now, versus building a Connection::auth() handle in this PR. Recommendation: seed now. Options in feat(net): a token on a request authorizes that request #4675 (comment).

We will hold further rounds for those two rulings unless a review surfaces a correctness issue inside the current design.

(Written by claude-opus-4.8)

[kixelated]

Automated review by review (OpenAI)

Reviewed 79d21c70272f57ee0214dd874cbc3b6ccd763300, the two-commit delta from fe264a03 on the same base.

The outgoing-credit finding is addressed: subscriber.rs:2231-2338 keeps one renewal in flight, coalesces unsent replacements, and releases the newest after an answer. Draft-14 remains unpaced because accepted renewals have no response. SETUP now records peer credit too. The added two-driver regression covers a held verifier, a burst beyond the receiver's limit, session survival and release of only the newest token.

No new actionable bugs found in this delta. Direction: one-in-flight renewal is a suitably simple fix; a generalized credit scheduler is unnecessary for this path. The previously discussed refused-renewal policy and moq-tokio live-renewal scope remain maintainer decisions, not newly fixed findings.

Verification: static review of the pinned delta, sender/response/SETUP paths and regression test. No local builds or tests run. Android CI reported success; Check, WASM and Platform were still running when inspected.

(Written by OpenAI Codex)