Repository navigation
quest: release-audio-group-cap waits on the release fix (#8118) - #8107
Conversation
Quest-Claim: b6f4c6316797c514
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 1 minute. 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. |
kixelated
left a comment
There was a problem hiding this comment.
Automated review by review (OpenAI)
Reviewed commit: 6f9cbb9
Base: ce0a4f0
No actionable findings in this bookkeeping change. The quest correctly remains open for the release merge and publication, points to #8118's actual release-only implementation, and requires checking that the published cut contains that merge rather than relying on a version number alone. No code or release action is performed here.
Verification: GitHub-only static inspection of the complete quest and the linked #8118 changes. I did not execute quest validation or query npm. Check was still in progress when checked.
(Written by review (OpenAI))
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
- Quest rescoped to
[XS]—quest/m0/release-audio-group-cap.mdnow states the remaining work is therelease-only fix in #8118 plus its patch publish, withmainexplicitly getting no change. - Waiting item added — a
Maintainer:wait to merge #8118 intorelease, cut the next@moq/publishpatch, and verify the published cut contains the merge commit.
I verified the plan's load-bearing claims instead of taking them from the body:
- #8118 is open against
release, mergeable, and its tests do exercise 2.5 ms frames atMAX_GROUP_FRAMESand 1 MiB frames atMAX_GROUP_CACHE_BYTESunder a 60 sgroupDuration. origin/releasestill definesMAX_GROUP_FRAMES = 8192andMAX_GROUP_CACHE_BYTES(32 MiB) injs/net/src/group.ts, whilemaindefines neither, so "main has no group cap" holds.origin/releasejs/publish/package.jsonand npmlatestare both 0.5.5, so the wait is not yet satisfied.quest check --base origin/main --branch pr-8107passes with "quest: 602 documents ok", matching the body.- Release PRs land as real merge commits (#7290 is
d0cff5ac8b, two parents), so "the release cut contains #8118's merge commit" is a check a later run can actually evaluate.
The prior plan hint to roll early like js/json's window encoder is superseded by #8118's exact-net-cap roll, which that PR's body documents; the rewritten Plan's "rolls at the net caps" matches the code.
deepseek-v4.1-flash-1017 (free via Pullfrog for OSS) | 𝕏

Claims quest/m0/release-audio-group-cap.md and rewrites it to what remains.
Summary
releaseonly: the audio encoder rolls a group beforeMAX_GROUP_FRAMES/MAX_GROUP_CACHE_BYTES.mainhas no group cap, so it gets no code change.main, rewrites the quest to[XS], points its Plan at moq-dev/moq#8118, and adds aMaintainer:## Waitingitem: merge it and cut the next@moq/publishpatch. A later PR deletes the quest once the patch publishes, as moq-dev/moq#7279 did forgroupDuration.Choices made without asking
mainand the fix must targetrelease, so one PR cannot do both. The claim PR carries the quest bookkeeping; the fix is a separatebackport/branch, since only claims use thequest/namespace. Merging this one first is fine: the quest then stays accurate, waiting on the release merge and publish.Public API: none. Wire: none.
Validation
quest check --base origin/main: 602 documents ok.Review
Skipped for head
6f9cbb9341: the diff only rewrites one quest file, whichquest checkvalidates. The code's review is on moq-dev/moq#8118 (Codexgpt-6.1-sol, medium, head2da8483b00, no findings).🤖 Generated with Claude Code
(Written by Claude Opus 5.5)