nestsClient: revert framesPerGroup default to 1 now that the QUIC fix lands frames

Production sweep_frames_200 confirms received=200/200 missing=[] after the
:quic MAX_STREAMS_UNI extension landed in d391ae1d. The framesPerGroup=5
mitigation in NestMoqLiteBroadcaster (commit 10ad69f1) is no longer
needed and was a workaround for a real QUIC bug; reverting to 1 brings
the wire shape in line with the JS reference broadcaster (one Opus frame
per moq-lite group → late-join initial gap drops from ≤100ms back to
≤20ms).

Tests that still want one-frame-per-group semantics keep their explicit
framesPerGroup=1 overrides — they pin the assumption independent of any
future default change. The broadcaster's framesPerGroup field kdoc is
updated to explain the history (mitigation → root-caused fix → revert).

All :quic and :nestsClient JVM tests pass.

Plan doc: nestsClient/plans/2026-05-01-quic-stream-cliff-investigation.md
status flipped to CLOSED with the production-validation numbers.
This commit is contained in:
Claude
2026-05-01 14:26:36 +00:00
parent d391ae1db9
commit c0269859b3
2 changed files with 32 additions and 29 deletions
@@ -1,7 +1,7 @@
# QUIC stream cliff against nostrnests.com — investigation plan
**Status: ROOT-CAUSED + FIXED.** Our `:quic` client never emitted
`MAX_STREAMS_*` frames to extend the peer-initiated stream-id cap.
**Status: CLOSED.** Our `:quic` client never emitted `MAX_STREAMS_*`
frames to extend the peer-initiated stream-id cap.
[QuicConnectionConfig.initialMaxStreamsUni] (default `100`) was the
*lifetime* maximum the peer could ever open. The relay forwards each
broadcast group as a fresh peer-initiated uni stream, so any
@@ -11,9 +11,13 @@ Fixed by tracking [QuicConnection.peerInitiatedUniCount] and emitting
peer's usage crosses the half-window threshold — same pattern as the
existing `MAX_DATA` / `MAX_STREAM_DATA` extension.
The `framesPerGroup = 5` mitigation in [NestMoqLiteBroadcaster] can
be reverted to `1` to match the JS reference broadcaster's wire
shape now that the underlying QUIC bug is gone.
Production validation: `sweep_frames_200` against `nostrnests.com`
went from `received=99/200 missing=[99-199]` (pre-fix) to
`received=200/200 missing=[]` (post-fix). The
[NestMoqLiteBroadcaster.DEFAULT_FRAMES_PER_GROUP] mitigation has
been reverted from `5` back to `1` so the broadcaster matches the
JS reference's wire shape (one Opus frame per moq-lite group → ≤ 20 ms
late-join initial gap).
**Reproduces against:** `https://moq.nostrnests.com:4443` (production
relay). Not consistently reproducible against the local