[kixelated]

Summary

Plans quest/m1/lite06-requests-end.md (S), a follow-up from moq-dev/moq#8516. There, a moq-lite-06 server's requests() loop did not end after its client cancelled, so the moq-ffi test a_credential_without_auth_is_unsupported aborts its server task instead. If the stream never ends, a server holds a task and session per departed lite-06 client, and lite-06 is still a version moq.pro relays interoperate on.

Decisions

• ✅ Plan it in m1 (rejected: m3; ignoring it). Decided 2026-11-11 by the maintainer at feat(auth)!: a credential is a handle that routes and claims name, in every binding #8516's merge pick.

Impact

Public API: none. Wire: none. Quest text only.

Follow-ups

None.

Models

Size: XS
Implementer: Claude Code, claude-opus-5-5, unknown effort

🤖 Generated with Claude Code

Review

Rewritten by quest review after each round.

• Reviewer: Codex, gpt-6.1-sol, low effort
• Session: 01a1cd8a-a22a-7a61-9441-06cedc64bccb, round 1
• Head: f0622a6
• Base: origin/main at 585c7f4
• Score: 10/10, The change only adds a follow-up quest documenting the suspected lifecycle issue and investigation plan, with no runtime behavior changes.
• Findings: none

[coderabbitai]

Pre-merge checks: 2

Failed checks: 2 inconclusive

Check name	Status	Explanation	Resolution
Title check		This assessment has not completed. The check will be retried on the next pre-merge check run.
Description check		This assessment has not completed. The check will be retried on the next pre-merge check run.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.

Share

• X
• Mastodon
• Reddit
• LinkedIn

[pullfrog]

ℹ️ Two details in the quest text worth tightening before an implementer picks this up.

Reviewed changes

• New m1 quest — quest/m1/lite06-requests-end.md records that a moq-lite-06 server's requests() stream never ends after its client cancels, and plans a moq-net/moq-tokio reproduction plus dropping serving.abort() from the moq-ffi test.

The claim about #8516's test matches its merged text exactly, and the lite-07 / moq-transport comparison holds (both of those tests await the server task).

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using deepseek-v4.1-flash-1017 (free via Pullfrog for OSS) ｜ 𝕏}

[pullfrog]

The queue has a second closer, and it is the one a departed peer should trigger: Supervisor::poll in rs/moq-net/src/session.rs:734 calls auth.close(...) as soon as the transport reports closed, on every protocol. Since Handle::close closes the app's Acceptor::App queue, saying the lite drivers are the only path leaves out the code that should already have ended this stream on lite-06, which changes what the implementer instruments first.

Technical details

# The supervisor also closes the auth queue

## Affected sites
- `quest/m1/lite06-requests-end.md:21-23` — says every moq-lite version reaches `Handle::close` only from `Driver::end` or `Driver`'s `Drop` in `rs/moq-net/src/lite/session.rs`.
- `rs/moq-net/src/session.rs:734` — `Supervisor::poll`, on `closed_watch.poll_closed`, calls `self.auth.close(err.clone())` before the protocol is polled (`rs/moq-net/src/driver.rs` polls the supervisor first).
- `rs/moq-net/src/auth.rs:1448` — `Handle::close` → `State::abort` returns the `Acceptor::App(queue)` → `Pending::close`, so `Requests::poll_next` yields `None`.

## Required outcome
- The plan names the supervisor's close-on-transport-close as the path that should end the stream when a peer leaves, and asks why it never fired for lite-06, rather than treating `Driver::end` as the only closer.

## Suggested approach (optional)
- Reword to name both, e.g. `Driver::end`/`Driver`'s `Drop` plus the session supervisor's close watch, and add "or its supervisor never saw the transport close" to the suspects.

[pullfrog]

requests() is on server::Handshake (rs/moq-net/src/server.rs:1143), returning auth::Requests; auth::Request is the per-token type and has no such method. Handshake::requests() (or just "the server's requests() stream") keeps the pointer accurate.