142 Commits

Author	SHA1	Message	Date
Claude	2bb55ff9ec	perf(quic): drop synchronized from QuicStream + replace close() polling with CompletableDeferred ... Round 2 of the blocking-code audit follow-ups. Both changes remove commonMain synchronized blocks and replace polling with event-driven suspension; :quic:jvmTest stays green on JVM and :quic:compileAndroidMain passes for Android. QuicStream.resetStream / stopSending - Replace synchronized(this) double-checked init with AtomicReference<ResetState?>.compareAndSet(null, …) (and same for stopSendingState). The pattern is "first call wins"; CAS expresses that directly without a lock. - Backing fields converted from `internal var … = null` to `internal val … = AtomicReference(null)`. The two readers in QuicConnectionWriter switch to .load(); QuicConnectionWriter gains a file-level @OptIn(ExperimentalAtomicApi::class). - The @Volatile resetEmitPending / stopSendingEmitPending writes happen only on the winning CAS path, so the writer reading the flag still sees the populated state via volatile happens-before. QuicConnectionDriver.close polling loop - Replace `while (status == CLOSING) delay(1)` polling with a CompletableDeferred<Unit> on QuicConnection (closingDrainSignal). The deferred is completed at both transitions to CLOSED: (1) drainOutbound after building the CONNECTION_CLOSE datagram, and (2) markClosedExternally on its synchronized first-call-wins path. - close() now awaits the deferred under the existing CLOSE_FLUSH_TIMEOUT_MILLIS bound — same upper-bound semantics, no 1 ms wakeups during teardown. complete(Unit) is idempotent, so the two transition sites racing each other is safe. https://claude.ai/code/session_01CXTjnuHKCNXDmpfyKxgG3V	2026-05-09 03:13:57 +00:00
Claude	0e4b12654d	perf(quic): lock-free hot paths — ThreadLocal Cipher, AtomicReference close, @Volatile getters ... Audit of blocking and synchronized code in the QUIC module surfaced four hot-path wins, all verified against :quic:jvmTest. - PlatformCrypto: header-protection AES-ECB now uses a per-thread cached Cipher. Previously every inbound and outbound packet paid for Cipher.getInstance("AES/ECB/NoPadding") provider lookup. ThreadLocal is safe because the call is stateless — every invocation re-init's with the caller-supplied key. - JdkCertificateValidator: gate the SAN-side InetAddress.getByName behind looksLikeIpLiteral so a malformed cert with a hostname in a type 7 SAN cannot trigger DNS resolution on the TLS validation path. - QuicConnectionDriver.close: replace synchronized(this) double-checked init with AtomicReference<Job?> + compareAndSet on a CoroutineStart.LAZY job. Lock-free, removes a synchronized from commonMain, preserves the original "first caller wins, second awaits same Job" contract. - SendBuffer: mark _nextOffset, nextSendOffset, _finPending, _finSent, _finAcked @Volatile and drop synchronized from their single-field getters (nextOffset, sentOffset, finPending, finSent, finAcked). The compound-formula readableBytes getter still synchronizes. https://claude.ai/code/session_01CXTjnuHKCNXDmpfyKxgG3V	2026-05-09 03:13:57 +00:00
Claude	2be76c898c	fix(quic): resolve dangling KDoc lint errors ... Move the feedDatagram KDoc below the MAX_QUIC_OFFSET const so it attaches to the function declaration, and merge the duplicate KDoc blocks above TlsResumptionState into a single block.	2026-05-09 01:40:48 +00:00
Claude	df6103ffdd	fix(quic): PSL subset, JCA ChaCha20-Poly1305, truthful ECN reporting ... Round 13 — three architectural follow-ups + a closeout note. * JdkCertificateValidator: ship a hand-picked Public Suffix List subset covering the high-volume multi-label effective-TLDs (multi-tenant ccTLDs and major hosting platforms). Pre-fix the dot-count heuristic accepted `*.co.uk`, `*.s3.amazonaws.com`, `*.github.io`, etc. — wildcards spanning these would impersonate every co-tenant. The new MULTI_LABEL_PUBLIC_SUFFIXES set adds a layer above the dot-count check; combined with the WebPKI / CT ecosystem already requiring CAs to consult the full PSL when issuing, this closes the practical attack surfaces. Full ~9000-entry PSL data shipping is still deferred (data-shipping ask, doc'd); a domain not in the subset that's also a multi-label ETLD remains a gap. * JcaChaCha20Poly1305Aead: new JCA-backed implementation mirroring JcaAesGcmAead's shape (cached Cipher + SecretKeySpec, range overloads via Cipher.doFinal(input, off, len, output, outOff), recent-nonce history for legitimate IV reuse on the Initial-padding rebuild path). bestChaCha20Poly1305Aead(key) expect/actual factory tries the JCA path first (Java 11+ / Android API 28+) and falls back to the pure-Kotlin ChaCha20Poly1305Aead singleton if the algorithm isn't available (older Android, headless GraalVM native-image without the standard providers). PacketProtectionBuilder routes the ChaCha20-Poly1305 cipher suite through the factory instead of the singleton. On supporting platforms this gives the same outbound-allocation savings as round 8's AES-GCM range overload. * QuicConnectionWriter: stop emitting fake ECN counts on ACK frames. Pre-fix every 1-RTT ACK carried `AckEcnCounts(0, 0, 0)` — claiming to track ECN while actually never reading inbound TOS bits. RFC 9000 §13.4.2: "An endpoint that uses ECN MUST report accurate ECN counts." Hardcoded zeros could be flagged as a PROTOCOL_VIOLATION by strict peers cross-validating against outbound packet counts; aioquic / picoquic / quic-go tolerate it but other stacks may not. With ecnCounts = null we honestly advertise "this endpoint isn't reporting ECN", peer skips its own ECN-driven congestion logic for our direction. We still mark outbound ECT(0) (other peers' tracking benefits from the path-quality signal); RFC 9000 §13.4 allows the asymmetry. * MutableSharedFlow migration for QuicStream.incoming declined as obviated. The audit's suggestion was a workaround for the cancel-coupling specifically (collector cancel → channel cancel → INTERNAL_ERROR) — round 11's `flow { for (c in incomingChannel) emit(c) }` wrapper solved that. Switching to MutableSharedFlow would change the semantics from "each byte to exactly one consumer" (correct for stream bytes) to fan-out (every emission to all collectors), which is wrong for QUIC stream data. All 269 :quic:jvmTest tests pass. BUILD SUCCESSFUL in 40s. https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM	2026-05-09 01:06:32 +00:00
Claude	953869714b	fix(quic): visibility, scratch caching, retransmit coalescing, secret hygiene ... Round 12 — six smaller follow-ups across visibility, perf, and secret-handling. * QuicStream.receiveDirtyForFlowControl gains @Volatile. The parser's read-loop writes the flag and the writer's send-loop reads it WITHOUT holding the same lock; without volatile the writer could miss the parser's update for an unbounded time on JVM (the field is hot in a drain loop where the JIT might cache it), suppressing MAX_STREAM_DATA emissions until something else triggered a fresh load. * SendBuffer.readableBytes runs in O(1) instead of O(R) by maintaining a cached `retransmitTotalBytes` counter. Updated in lockstep with every retransmit deque mutation: addLast in [requeueAllInflight] + the two paths in [removeOverlap] (RETRANSMIT zero-length + main range), and add/removeFirst in [takeChunk]. Pre-flight "anything to send?" check on the writer's hot path was previously walking the deque per-stream per-drain. * SendBuffer.requeueAllInflight coalesces adjacent ranges on insert. Pre-fix the PTO probe path appended each in-flight range as a separate retransmit entry, so on the next drain takeChunk emitted one tiny STREAM frame per original-packet boundary. With coalescing, contiguous bytes get replayed as one chunk + one AEAD seal. FIN-bearing ranges stay separate (merging across a FIN changes the implicit final-size invariant). * TlsResumptionState dropped `data class`. The auto-generated equals/hashCode used reference equality on its ByteArray fields (PSK / ticket / peerTransportParameters), so two byte-identical states compared unequal — almost never useful and a footgun for caller-side caches. The auto-toString would dump PSK contents into any log. Replaced with hand-written equals/hashCode using contentEquals on the byte fields and a redacted toString that reveals only sizes. * QuicConnectionParser RESET_STREAM handler bounds finalSize at [0, 2^62-1] per RFC 9000 §16 (the QUIC offset ceiling). Pre-fix we accepted any varint, including values that could overflow downstream Long math. * PathChallenge/PathResponse IAE leak: re-traced and verified non-issue. The decoder calls `r.readBytes(8)`, which either throws QuicCodecException (short read) or returns exactly 8 bytes — the constructor's `require(data.size == 8)` is unreachable from the decode path. The audit was over-cautious; no code change. All 269 :quic:jvmTest tests pass. BUILD SUCCESSFUL in 39s. https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM	2026-05-09 00:59:28 +00:00
Claude	e7b7d99582	perf(quic): outbound AEAD allocation, scratch reuse, sort skip + key-update + flow ... Round 11 — six follow-ups across perf, correctness, and API hygiene. * QuicStream.incoming: replace `consumeAsFlow()` with `flow { for (c in incomingChannel) emit(c) }`. Pre-fix the consume-style flow cancelled the underlying Channel when the collector terminated, which coupled "application stopped reading" with "parser INTERNAL_ERRORs the connection on next delivery". The new emit-only flow leaves the channel open across collector cancellation, so applications can stop reading temporarily and resume later (sequential collects, not concurrent — that's still a race on the channel iterator). * RFC 9001 §6.1 client-initiated key update: the existing [QuicConnection.initiateKeyUpdate] no longer requires the caller to enforce spec invariants. Returns false if the handshake isn't yet complete (§6.5: MUST NOT initiate before HANDSHAKE_DONE) or if a previous rotation is still in flight (§6.4: MUST NOT initiate a subsequent update until the previous one is confirmed). The parser clears the [keyUpdateInProgress] flag on the first inbound packet that AEAD-decrypts under the post-rotation live keys — the confirmation signal that the peer has rolled forward. * Aead.sealInto: new range + in-place seal that writes ciphertext+tag DIRECTLY into a caller-supplied output buffer at a given offset. Default impl falls back to sealRange + copy; JcaAesGcmAead overrides to use Cipher.doFinal(input, inOff, inLen, output, outOff). LongHeaderPacket.build / ShortHeaderPacket.build now pre-allocate the final packet buffer in a single shot and have the AEAD write ciphertext+tag in-place. Pre-fix every outbound packet allocated 4 ByteArrays (headerBytes, paddedPlaintext, ciphertext, concat buffer); now ~2 (the final packet + the AEAD provider's internal scratch). * QuicConnectionWriter.drainOutbound: skip the `active.sortedByDescending { priority }` allocation when EVERY active stream shares the same priority — not just the default-zero case. A homogeneous priority-7 workload now keeps insertion order at no cost. * QuicConnection.scratchAppFrames / scratchAppTokens: per-connection reusable lists for buildApplicationPacket. Cleared at function entry, re-used across drains under streamsLock's single-writer guarantee. The tokens list is `.toList()`-snapshotted into the SentPacket record before reuse, so retransmit dispatch is unaffected. NOT applied to collectHandshakeLevelFrames because its returned [HandshakeLevelContents] is held across two buildLongHeaderFromFrames calls (natural-size + padded rebuild) in drainOutbound. * Removed dead `parts = mutableListOf<ByteArray>()` declaration at the top of drainOutbound — never referenced; the actual datagram assembly uses inline `listOfNotNull(...)` instead. All 269 :quic:jvmTest tests pass. BUILD SUCCESSFUL in 43s. https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM	2026-05-09 00:50:36 +00:00
Claude	b097580fdd	fix(quic): TLS PSK rejection — recover in-place instead of failing ... Round 10 — supersedes the typed-exception approach from round 9. Round 9 introduced [PskRejectedException] as a "punt to the application layer" hack, with a comment claiming the in-place fallback was too subtle to land safely. After tracing the actual derivation path the fix turns out to be one line. The key observation: the on-wire ClientHello (with `pre_shared_key` extension and binder bytes) goes into BOTH client and server transcript hashes regardless of accept / reject (RFC 8446 §4.2.11). The transcript hash itself doesn't need any rebuild. The ONLY thing that differs between accept and reject is how [earlySecret] is derived: * accepted: HKDF-Extract(0, PSK) * rejected: HKDF-Extract(0, 0) ← same as no-resumption path So when the server returns ServerHello without `pre_shared_key`, we simply call `keySchedule.deriveEarly()` to overwrite the PSK-derived [earlySecret] with the zero-keyed value. [deriveHandshake] runs immediately after with the new earlySecret + ECDHE shared secret, and the handshake proceeds along the regular non-resumption path (which is well-tested by every non-resumption test in the suite). * `pskAccepted = false` so the WAITING_CERTIFICATE_OR_FINISHED state correctly demands Certificate + CertificateVerify (a Finished without those would still be rejected as unauthenticated). * Any 0-RTT packets the application emitted under the PSK-derived [clientEarlyTrafficSecret] are lost — server can't decrypt them and EncryptedExtensions arrives without the early_data extension, so [earlyDataAccepted] = false. The application layer is responsible for replaying any 0-RTT-bound payload over 1-RTT. The handshake itself proceeds cleanly. * [PskRejectedException] (added in round 9) deleted as dead code. [QuicCodecException] reverts to a `final` class. All 269 :quic:jvmTest tests pass. The fallback re-uses the deriveEarly() codepath that every non-resumption test exercises, so test coverage is implicit in the existing suite. https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM	2026-05-09 00:33:09 +00:00
Claude	28c1a355da	fix(quic): RFC 9002 §6.1.2 loss-detection timer + PSK rejection signal ... Round 9 — the two largest items remaining from the audit. * RFC 9002 §6.1.2 timer-driven loss detection. [detectAndRemoveLost] now returns a [Result] data class carrying both the list of lost packets and the absolute monotonic deadline at which the next earliest sub-largest in-flight packet will cross the time threshold. The parser stores that deadline on each [LevelState.nextLossTimeMs] per encryption level, and the driver's send loop now sleeps for `min(ptoDeadline, minNextLossTimeAcrossLevels) - now`. On expiry, the driver distinguishes: * Loss-timer wake → run [detectAndRemoveLost] across all levels; declare time-threshold-lost packets and dispatch their tokens. No probe budget, no exponential backoff. * PTO wake → existing [handlePtoFired] path (probe + backoff). Pre-fix tail loss waited for the full PTO (often 5x the time threshold) before retransmitting because we had no event between ACK arrivals to fire loss detection. Now `9/8 * max_rtt` is the ceiling. * TLS PSK rejection: instead of the prior generic [QuicCodecException] ("server rejected PSK; full-handshake fallback not implemented"), raise a typed [PskRejectedException] subclass. Application reconnect logic can selectively catch this and retry the handshake without cached resumption state — a path that's correct by construction (fresh ClientHello, no PSK history, no transcript-rebuild complexity). [QuicCodecException] is now `open` so the subclass can extend it. In-place fallback (clear early secret, rebuild transcript without PSK extension, replay derivation) remains deferred — the subtle transcript-hash discrepancies it could introduce would be much harder to debug than a hard failure that the application intentionally turns into a retry. All 269 :quic:jvmTest tests pass. BUILD SUCCESSFUL in 47s. https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM	2026-05-09 00:23:37 +00:00
Claude	90f59a3351	perf(quic): AEAD range overload + doc notes for known fragile couplings ... Round 8 — AEAD allocation reduction on the receive hot path, plus the documentation of two known-fragile-but-not-broken couplings. * Aead gains [openRange] / [sealRange] taking (array, offset, length) triples for AAD and plaintext/ciphertext. Default impls slice and delegate to the existing whole-array methods so non-JCA AEADs (Aes128Gcm singleton, ChaCha20Poly1305Aead) still work. The JCA-backed [JcaAesGcmAead] overrides both, passing offsets straight to `Cipher.updateAAD(byte[], offset, len)` and `Cipher.doFinal(byte[], inputOffset, inputLen)` — JCA accepts ranges natively and does no internal copies. Saves ~2 KB ByteArray allocations per inbound packet (one for the header `aad`, one for the `ciphertext`) — at audio-room receive rates (~100 packets/sec) that's ~12 MB/min of GC churn eliminated. Same overload on the outbound path is wired but currently exercised less because the build path constructs `headerBytes` and `paddedPlaintext` as separate fresh allocations. parseAndDecrypt in both ShortHeaderPacket and LongHeaderPacket now call openRange instead of slicing into intermediates. * JdkCertificateValidator.dnsMatches: explicit doc note on the public-suffix-list gap. The dot-count heuristic accepts wildcards like `*.co.uk` / `*.github.io` / `*.s3.amazonaws.com` whose effective TLD spans multiple labels. WebPKI / CT logging mitigates this in practice (CAs validate against the actual PSL), but our local validation alone wouldn't catch a rogue cert. Production callers for sensitive endpoints should rely on OS / NetworkSecurityConfig pinning rather than QUIC's hostname check alone. Full PSL data shipping deferred until justified. * QuicStream.incoming: explicit doc note on the single-collector contract. [consumeAsFlow] cancels the underlying [Channel] when its collector terminates, and once cancelled the parser's next trySend fails, sets [overflowed] = true, and the parser tears down the connection with INTERNAL_ERROR. Production callers already follow single-collector + collect-until-FIN, but the doc lays out the rule so a future refactor doesn't loosen it accidentally. Long-form discussion of the `MutableSharedFlow` alternative and why we declined it. All 269 :quic:jvmTest tests pass. BUILD SUCCESSFUL in 40s. https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM	2026-05-09 00:17:19 +00:00
Claude	f987b3dfe2	fix(quic): SETTINGS validation, sensitive headers, peer-stream count, drain alloc ... Round 7 — closing out the audit's spec/correctness/perf quick wins. * WtPeerStreamDemux: validate peer SETTINGS includes ENABLE_WEBTRANSPORT=1 AND ENABLE_CONNECT_PROTOCOL=1 (draft-ietf-webtrans-http3 §3 + RFC 8441). Pre-fix we accepted any SETTINGS and proceeded to Extended CONNECT, which the server then rejects with no diagnostic for the application. Now surfaces as a typed protocol error on peerH3ProtocolError so the QUIC layer closes deliberately. * QpackEncoder: set N=1 (never-indexed) on literal field lines for authorization / cookie / set-cookie / proxy-authorization per RFC 9204 §4.5.4. Pre-fix sensitive credentials could be cached by intermediate QPACK encoder caches. * QuicConnection.getOrCreatePeerStreamLocked: track peerInitiated*Count via max(current, peerIndex+1) instead of += 1. The counter now derives from the stream id's index field (RFC 9000 §2.1) and is idempotent against retransmits-after-eviction. Pre-fix a peer retransmit on a stream id that aged out of the retired-IDs FIFO bumped the counter again, eventually triggering spurious MAX_STREAMS_* emissions. * applyPeerRetireConnectionIdLocked: reclassify the close-on-seq=0 case as PROTOCOL_VIOLATION (peer fault) instead of INTERNAL_ERROR (our fault). The diagnostic was misleading — the peer IS misbehaving (asking us to retire our only SCID with no replacement available), not us. * QuicConnectionWriter.drainOutbound: skip the `streamsView.filter { !it.isClosed }` allocation when no streams are closed. Quick `any` scan first; only allocate the filtered list when at least one stream is actually closed. Saves an N-sized ArrayList per drain in the common case (~50 drains/sec × N up to ~2000 streams under multiplex load). All 269 :quic:jvmTest tests pass. BUILD SUCCESSFUL in 40s. https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM	2026-05-09 00:14:07 +00:00
Claude	5421b81569	perf(quic): QPACK Huffman decode — no boxing, IntArray + binary search ... Pre-fix QpackHuffman.decode allocated two boxed Integers per output character: one for the `candidate` Int passed into `HashMap<Int, Int>.get` and one for the wrapper-Integer return value. Output also went through `ArrayList<Byte>`, boxing every emitted byte as a `java.lang.Byte` (~16 bytes per output byte on a 64-bit JVM). On a typical HTTP/3 response with ~30 header values, that's hundreds of throwaway wrapper objects per request — pure GC churn on the hot path. The new layout keeps two parallel `IntArray`s per code-length: codes[len] (sorted ascending) and syms[len] (the matching symbol indices). Lookup is a primitive `IntArray.binarySearch(candidate)` — no boxing, the array stays in JIT-friendly contiguous memory, and the per-length arrays are tiny (a few entries each, since the Huffman table is sparse at any given length). Output uses a growable `ByteArray` with a manual position index rather than `ArrayList<Byte>`. Pre-grow to 2× input size as a rough upper bound — ASCII headers compress to ~62% with HPACK Huffman, so we rarely need to grow. Also fixes a latent bug: the new init loop covers lengths 5..30 (previously 5..29), restoring decoding for symbols 10 (LF), 13 (CR), 22 (DC2) which all use 30-bit codes per RFC 7541 Appendix B. Pre-rewrite the HashMap path included these via `for (sym in 0..255)` walking the full symbol table; the IntArray rewrite needed an explicit length range and accidentally cut at 29. Added a unit test exercising hand-encoded length-30 inputs to lock the fix in. Behavior verified against RFC 7541 Appendix C test vectors and the new length-30 round-trip. All 269 :quic:jvmTest tests pass. https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM	2026-05-09 00:03:39 +00:00
Claude	ce8d852518	fix(quic): final stabilization sweep — CID picking, atomic gates, defensive checks ... Round 5 of the audit follow-ups. The remaining low-leverage items from the original audit all addressed in one pass. * PathValidator: pick the smallest spare CID sequence number rather than LinkedHashMap insertion order. RFC 9000 §19.15 lets the peer issue NEW_CONNECTION_ID out of sequence (e.g. retransmits arriving after newer offers); insertion-order picking would land on whichever offer arrived first instead of the lowest seq, drifting away from the RFC-expected ordering. forceRotateToHigherSequence also now filters >= retirePriorToWatermark explicitly so we never pick a sequence below the watermark even if the pool somehow holds one. * QuicWebTransportSessionState.close: driver.wakeup() AFTER enqueuing the WT_CLOSE_SESSION capsule + FIN but BEFORE driver.close, so the capsule actually reaches the wire instead of being short-circuited by the driver shutdown. Pre-fix the peer saw an abrupt UDP-level tear-down with no application-error-code surfaced. * QuicStream.resetStream / stopSending: synchronized(this) atomic CAS for the "first call wins" gate. Pre-fix two concurrent callers could both observe `resetState == null` and both write — the second caller's errorCode would clobber the first while resetEmitPending was already set, so the writer emitted the RESET_STREAM with whichever value landed last. * Http3Settings.decodeBody: per-id value range checks. A peer that advertises e.g. MAX_FIELD_SECTION_SIZE = 2^60 could otherwise drive our encoder into unbounded heap. Bounds chosen above any legitimate value (1 GiB for table-capacity / field-section caps, 1 for boolean flags) and below 2^32 for unknown ids. * Privatize crypto-relevant static byte arrays: InitialSecrets.V1_INITIAL_SALT, RetryPacket.V1_RETRY_KEY, RetryPacket.V1_RETRY_NONCE. Pre-fix these were public mutable ByteArrays — any caller could stomp on them, and any toString / reflection would leak the bytes. Crypto material doesn't need to be reachable outside the deriving / sealing path. * peekHeader length cast: re-verified as already safe (lengthRaw is bounded by r.remaining before .toInt() — Int.MAX_VALUE ceiling enforced). All 269 :quic:jvmTest tests pass. BUILD SUCCESSFUL in 2m 17s. https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM	2026-05-08 23:57:34 +00:00
Claude	e4d96421c2	fix(quic): reserved-bit checks, TLS bounds, SendBuffer shrink ... Round 4 of the audit follow-ups. * Reserved-bit enforcement on unmasked QUIC headers (RFC 9000 §17.2 / §17.3.1). Pre-fix the parser silently accepted long-header packets with bits 0x0C set or short-header packets with bits 0x18 set after HP unmasking — the spec mandates PROTOCOL_VIOLATION close. Added [QuicProtocolViolationException] and a top-level catch in feedDatagram that translates the throw into markClosedExternally. Long-header parse also drops a now-dead `if form==1` branch on the first-byte mask: we already early-returned in non-long paths above, so the mask is always 0x0F. * TLS handshake-message bounds: - TlsCertificateChain.decodeBody: reject `listLen > r.remaining` up front; assert `r.position == end` after the cert loop. Without this, a malicious peer could push us into reading past the message limit on per-cert extensions. - TlsServerHello.decodeBody / TlsEncryptedExtensions.decodeBody: reject trailing bytes after the extensions block. - TlsEncryptedExtensions.alpn: enforce RFC 7301 §3.1 (server returns EXACTLY one protocol_name); validate outerLen matches remaining and reject multi-name responses. * SendBuffer.data shrink: pre-fix the doubling-on-grow buffer never shrank, so a stream that ever held N bytes pinned `data.size = N` for the connection's lifetime. Long-tail memory retention on per-stream basis. advanceFlushedFloorIfPossible now releases capacity once live bytes occupy ≤ 1/4 of the allocation, shrinking to max(SHRINK_FLOOR_BYTES=4096, 2*dataLen). Below the floor the doubling cost is negligible; above it the multi-MiB transients release back to the heap. All 269 :quic:jvmTest tests pass. BUILD SUCCESSFUL in 47s. https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM	2026-05-08 23:40:20 +00:00
Claude	392df0384b	fix(quic): HTTP/3 stream-context validation + ReceiveBuffer perf cliff ... Round 3 of the audit follow-ups. * Http3FrameReader gains a [StreamContext] parameter that enforces RFC 9114 §7.2 per-stream rules: - CONTROL: first frame MUST be SETTINGS (else H3_MISSING_SETTINGS); duplicate SETTINGS, DATA, HEADERS, PUSH_PROMISE all forbidden. - REQUEST: SETTINGS / GOAWAY / MAX_PUSH_ID / CANCEL_PUSH forbidden. - PUSH: similar set including PUSH_PROMISE. - Reserved types 0x02 / 0x06 / 0x08 / 0x09 explicitly rejected. - WT_BIDI_DATA / WT_UNI_DATA: reader is the wrong tool, throw. - UNCHECKED preserves prior test behaviour and is the default. WtPeerStreamDemux's CONTROL drain now constructs the reader with StreamContext.CONTROL, so a buggy server can no longer slip a DATA frame into our SETTINGS expectations and silently confuse the parser. The validation throws QuicCodecException, which the drainControlStream catch records on a new peerH3ProtocolError field — the QUIC layer / application reads it to close with the proper diagnostic instead of having the route() catch swallow it. * ReceiveBuffer no longer coalesces overlapping segments on insert. Pre-fix every reorder fill allocated a fresh merged ByteArray of size (hi - lo) and copyInto'd each existing segment — under a 200- chunk reorder burst that was O(N²) bytes. The new layout keeps segments as a sorted, non-overlapping list (binary-searched on insert) and only allocates at readContiguous time, where it walks consecutive segments and concats them in a single pass. Adjacent segments are not eagerly merged — the read-side concat is bounded by the contiguous prefix the consumer is about to drain anyway. bufferedAhead becomes O(1) (cached counter) instead of O(N) sum. * New tests cover the per-context rejection paths (CONTROL-stream first-frame check, DATA-on-control, SETTINGS-on-request, all four reserved frame types). All 269 :quic:jvmTest tests pass. BUILD SUCCESSFUL. https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM	2026-05-08 23:30:17 +00:00
Claude	5c534b1774	fix(quic): bound peer-controlled buffers and channels — DoS hardening ... Round 2 of the audit follow-ups. Each item caps a peer-controlled allocation that pre-fix could be inflated to hold gigabytes of heap or pin a CPU core indefinitely. * Http3FrameReader: cap pending unparsed buffer (1 MiB) and per-frame body length (16 MiB). A peer streaming a partial-frame prefix without ever delivering the body now raises QuicCodecException instead of growing buf indefinitely. * CapsuleReader: cap pending buffer (1 MiB) and per-capsule body (64 KiB). Symmetric encoder-side check on WT_CLOSE_SESSION reason size, matching the existing decoder cap. * WtPeerStreamDemux: replace Channel.UNLIMITED with bounded channels + suspending sends. readyStreams now caps queued peer-initiated streams at 1024; per-stream chunkChannel caps at 64 chunks. The collector's suspending send naturally back-pressures via QUIC flow control when the application is slow, rather than pinning heap. * WtDatagram.decode: validate quarter-id is in [0, (2^62-1)/4] so `r.value * 4` cannot overflow Long and wrap into a small signed value matching our session id (cross-session datagram injection). * QuicReader.readBytes / skip: translate negative-count into typed QuicCodecException instead of letting IllegalArgumentException escape from copyOfRange. * AckTracker: cap stored disjoint ranges at 64. A peer that sends alternating-bit-pattern PNs can no longer grow our ACK frame past what fits in a packet; oldest range evicts on overflow. * JcaAesGcmAead: track recent encrypt nonces (8) instead of just the most-recent, so a single intermediate seal between two rebuilds can't mask a duplicate against the second-most-recent. Drop the remembered nonce on doFinal failure so a retry takes the safe fresh-Cipher path. Add synchronized() defence-in-depth. Each cap has a generous default (above any legitimate use) but finite. Tests use no-arg construction; existing call sites unaffected. All 269 :quic:jvmTest tests pass. https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM	2026-05-08 23:12:37 +00:00
Claude	b25644bf8b	fix(quic): stabilization pass — concurrency, RFC compliance, DoS hardening ... Verified and applied 12 focused fixes from a four-agent review of the quic module. Each fix verified against the actual code; agent findings that traced to false positives (pendingPing clear-without-emit, sentPackets on encrypt failure) are documented in the review thread but not changed. Concurrency / flakiness: - PTO consecutive count: double-increment removed; now incremented exactly once per PTO event in handlePtoFired before requeue, so the threshold check inside requeueInflightForProbe sees the post- increment value AND the between-probe re-requeue doesn't bump again. - Wallclock → monotonic: QuicConnection.nowMillis defaults to TimeSource.Monotonic anchored at construction, so NTP step / suspend-resume can't poison RTT samples. Driver uses connection.nowMillis instead of carrying its own clock. - Close-state race: atomic CAS via closeStateMonitor in close() and markClosedExternally so concurrent teardown paths can't both fire qlog "connection closed" and stomp on closeReason. - streamsList CME: converted to @Volatile var List<QuicStream> with immutable-snapshot publishing under streamsLock. closeAllSignals' iteration is now CME-free without holding the (suspending) lock. - JcaAesGcmAead: synchronized seal/open; multi-entry recent-nonce history (was single most-recent — could mask a duplicate against the second-most-recent under intermediate seals); on seal failure evict the cached nonce so a retry with the same nonce takes the safe fresh-Cipher path. Wire correctness / spec: - Connection-level send credit no longer debited on retransmits (added Chunk.isRetransmit; writer skips sendConnectionFlowConsumed += data.size when set). Pre-fix a few PTO rounds on a long stream exhausted credit and stalled the connection. - ACK-delay shl overflow: clamp ackDelayExponent to 0..20 and clamp the peer's varint to (Long.MAX_VALUE >>> exponent) before shift; clamp negative now-vs-recv-time before shift on outbound AckTracker. - Key-update commit only when new-phase packet PN exceeds largestReceived (RFC 9001 §6.1). - RESET_STREAM final-size validation: enforce equality with prior FIN size and ≥ highestObservedOffset; close FINAL_SIZE_ERROR otherwise. - STOP_SENDING handling: respond with RESET_STREAM on the local send side (was silently dropped, peer's flow-credit wasted). - ReceiveBuffer.insert: typed InsertResult; second FIN with conflicting size and offset-past-FIN data both surface FINAL_SIZE_ERROR via the parser instead of being silently dropped. - Retry SCID==DCID self-loop: reject Retry where the peer's SCID equals our original DCID (RFC 9000 §17.2.5.2). DoS hardening: - ACK PN walk: drainAckedSentPackets rewritten to scan in-flight keys against parsed ranges instead of walking every PN. A peer with firstAckRange = 2^62-1 used to pin a core forever; now bounded by the sent-packets map size. - UDP socket: channel.connect(remote) after bind so the kernel filters off-path datagrams. Stops trivial source spoofing from burning AEAD attempts. https://claude.ai/code/session_01AhGvbMV8uPRse3TmAGaddM	2026-05-08 22:56:05 +00:00
Vitor Pamplona	0c4bf031f1	fix(quic): RFC 9002 §6.2.4 — emit two ack-eliciting packets per PTO probe ... Single-packet probes need 6 PTO doublings (~19s) to land one datagram through the `amplificationlimit` interop scenario's 6-drop window. quic-go and msquic kill the connection at ~10s of silence regardless of our handshake-timeout budget, so we never recovered against them (diagnosed in the parent investigation; the 10s→30s timeout bump in 0a892b0d4b only fixed picoquic). RFC 9002 §6.2.4 allows up to 2 ack-eliciting packets per PTO. Adding the second probe halves recovery to ~3 PTO rounds (~5s) and lands within strict server tolerances. Wiring: - New `QuicConnection.pendingProbePackets`, set to 2 by handlePtoFired. - Extracted `requeueInflightForProbe` from handlePtoFired so the send loop can re-requeue inflight CRYPTO / STREAM bytes between probes. - Send loop decrements the budget after each probe-bearing send; if the budget is still positive, re-requeues AND re-arms `pendingPing` so the no-data fallback (post-handshake idle) still emits a second PING. Without the `pendingPing` re-arm, only the first probe fires when CRYPTO is fully ACK'd — `pendingPing` is one-shot in collectHandshakeLevelFrames. Verified end-to-end: - amplificationlimit: ✕→✓ vs quic-go (35s→7s); ✓ no-regression vs picoquic (19s→7s) and quinn (15s→7s); msquic now reports server- side UNSUPPORTED (was failing). Recovery times across the board drop ~3x because handshake-loss recovery is ~3 PTO rounds instead of ~6. - handshake / transfer / multiplexing / handshakeloss all green vs quic-go, quinn, picoquic, msquic — no regression on the core matrix. Tests: - New `ptoEmitsTwoProbePacketsPerRfc9002` in PtoCryptoRetransmitTest invokes the EXACT helpers the send loop uses (handlePtoFired then requeueInflightForProbe between drains) and asserts two distinct Initial datagrams with the same CRYPTO bytes at offset 0 on distinct PNs. Verified the test fails when budget is reverted to 1. - Existing PTO + recovery tests stay green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-08 17:06:28 -04:00
Claude	9ad4dbc356	fix(quic): replace deprecated lock with split locks in QlogObserverTest ... The post-handshake status check uses lifecycleLock (status is guarded by lifecycleLock per the lock-split refactor); the malformed-datagram test uses streamsLock since feedDatagram requires streamsLock.	2026-05-08 20:21:26 +00:00
Claude	07ba23a71c	fix(quic): second-pass audit fixes for path validation ... Three correctness bugs surfaced by post-fix re-audit, plus minor cleanups. - Bug A (validation hang): checkPathValidationTimeoutLocked was only called from handlePtoFired. PATH_CHALLENGE is ack-eliciting so the peer ACKs it; that ACK resets consecutivePtoCount, which means the PTO timer that used to host the budget check stops firing. Validation could hang indefinitely on a peer that ACKs but doesn't reply with PATH_RESPONSE. Fix: drive the budget check from drainOutbound (every send-loop wake). - Bug B (stale retire): under abrupt-migration semantics the prior CID is abandoned the moment we rotate. Queuing the retire only inside applyPathResponse meant two consecutive failed validations would leave the original seq=0 unretired forever. Fix: queue priorSeq in tryStartValidation; advance activeCidSequence at trigger time so it tracks the on-wire DCID. - Bug C (spec MUST violation): RFC 9000 §5.1.2 requires server- forced retirement of the active CID when the peer's retire_prior_to advances past it. Previously the parser silently accepted the offer and we kept stamping a now-retired CID. Fix: new PathValidator.forceRotateToHigherSequence; called from applyPeerNewConnectionIdLocked after a successful Stored result. No PATH_CHALLENGE needed (same path, just different CID). Closes connection with CONNECTION_ID_LIMIT_ERROR if the pool is empty when forced rotation is needed. Concurrency: - Add @Volatile to consecutivePtoCount. The driver kdoc claimed it already was; it wasn't. The send-loop reads it lockless for backoff calculation while three writers mutate it (driver PTO fire, parser ACK reset, applyPeerPathResponseLocked reset). Cleanup: - Drop redundant destinationConnectionId re-stamp in applyPeerPathResponseLocked (already rotated at challenge time). - Fix PathMigrationResult kdoc to acknowledge that NotConnected is produced only by the connection-level wrapper. - Update applyPeerNewConnectionIdLocked kdoc with the §5.1.2 forced-rotation contract. Tests: - PathValidatorTest: + triggerRetiresPriorSequenceImmediately (Bug B) + twoConsecutiveFailedValidationsRetireAllAbandonedSequences (Bug B regression — would have caught the original miss) + forceRotateRunsWhenWatermarkPassesActiveCid (Bug C) + forceRotateNoOpWhenWatermarkBelowActive (Bug C edge) + forceRotateRotatesAgainWhenNewerOfferAdvancesWatermark (Bug C cascading) - ClientPathMigrationTest: + newConnectionIdWithRetirePriorToPastActiveForcesRotationOnSamePath (Bug C wire-level) + Updated fullMigrationRoundTrip to assert RETIRE rides in the same packet as PATH_CHALLENGE under abrupt-migration semantics. + Updated pathResponseWithMismatchingPayloadKeepsValidatingAndDcid to reflect activeCidSequence advances at trigger time. All :quic:jvmTest (39 tests in path-validation suite) and :nestsClient:jvmTest pass. https://claude.ai/code/session_01PVVhSQXvw4K4oQ46FzpgaT	2026-05-08 19:57:55 +00:00
Claude	9b9ede2e1e	fix(quic): audit fixes for client path validation + DCID rotation ... Addresses seven bugs surfaced by post-landing audit of the path validation feature. Spec fixes (RFC 9000 §9): - Bug 1: PATH_CHALLENGE was going out on the OLD DCID because the writer reads conn.destinationConnectionId per packet and the rotation only happened on PATH_RESPONSE arrival. Now rotate the DCID inside triggerPathMigrationLocked (abrupt-migration model appropriate for the "old path looks dead" trigger condition). Fixes the headline feature — without this the challenge cannot actually exercise the new path. - Bug 2: 3 * PTO timeout dropped the failed CID without queuing a RETIRE_CONNECTION_ID. The peer kept the routing entry forever. checkValidationTimeout now queues the failed sequence per §5.1.2. - Bug 3: RETIRE_CONNECTION_ID for seq 0 was silently honored. We have no replacement SCID to give the peer (we don't issue our own NEW_CONNECTION_ID frames), so the connection is unusable. Close with INTERNAL_ERROR instead. - Bug 4: triggerPathMigration had no handshake-confirmed gate; §9.1 forbids migration before handshake confirmation. Returns new PathMigrationResult.NotConnected when status != CONNECTED. Implementation fixes: - Bug 5: driver was calling Clock.System.now() directly instead of conn.nowMillis(), breaking virtual-clock tests. - Bug 6: PTO threshold check ran BEFORE the consecutive-PTO counter increment, so threshold=2 actually required 3 PTOs. Increment first; threshold semantics now match the constant. - Bug 7: applyPeerPathResponseLocked didn't reset consecutivePtoCount on successful validation; the next sleep inherited a stale exponential-backoff multiplier even though the peer just proved liveness. Code quality: - Rename ValidationOutcome.Validated.newConnectionIdBytes → connectionId; PathValidationState.Validating.newCidBytes → newConnectionId. The "Bytes" suffix was redundant. - Drop unused PathValidator(initialActiveCidSequence) parameter. - Drop dead coerceAtLeast(2) in pool size calculation. - Make pendingChallenges and pendingRetireSequences internal. - Fix stale KDoc references (activatePendingValidatedCid, forceRetireActiveIfNeeded, "retirePriorTo decreased" — none survived the §19.15 clamp fix). - PathValidator.RecordResult: drop RetirePriorToRegressed enum value (clamped, never returned). - Surface qlogObserver.onConnectionIdRetired in both the success and timeout paths. Tests: - ClientPathMigrationTest: existing fullMigrationRoundTrip test now asserts DCID rotates AT challenge time, not on PATH_RESPONSE. - New retireConnectionIdForSequenceZeroClosesConnection. - New pathResponseSuccessResetsConsecutivePtoCount. - New triggerPathMigrationBeforeHandshakeReturnsNotConnected. - PathValidatorTest: validationTimeoutAfter3PtoTransitionsToFailedAndRetiresFailedCid now asserts the failed sequence is queued for retire. - retirePriorToRegressionIsRejected → renamed to retirePriorToRegressionIsClampedNotRejected. All :quic:jvmTest and :nestsClient:jvmTest pass. https://claude.ai/code/session_01PVVhSQXvw4K4oQ46FzpgaT	2026-05-08 19:37:33 +00:00
Claude	435c49bae9	feat(quic): client-initiated path validation + DCID rotation (RFC 9000 §9) ... Implements the client side of connection migration so a path that stops receiving ACKs (NAT rebind, route flap, dead peer) can be recovered without a fresh handshake: 1. NEW_CONNECTION_ID frames from the server are stored in a PathValidator pool (was: parsed and dropped). 2. After PATH_PROBE_PTO_THRESHOLD consecutive PTOs, the driver calls triggerPathMigrationLocked(); the validator picks an unused CID and queues a PATH_CHALLENGE with a CSPRNG payload. 3. The writer drains the challenge into the next outbound 1-RTT packet using the new DCID; a RecoveryToken.PathChallenge is attached so loss recovery can re-queue on packet drop. 4. Inbound PATH_RESPONSE that byte-equals the outstanding payload promotes destinationConnectionId to the new bytes and queues RETIRE_CONNECTION_ID for the prior sequence. 5. RFC 9000 §8.2.4: validation is abandoned after 3 * PTO; timeout transitions to PathValidationState.Failed for retry. Spec coverage: - §5.1.1 initial DCID is sequence 0 - §5.1.2 retire_prior_to enforcement (clamping per §19.15 reordering rule, force-retire of cached entries below watermark) - §8.2.2 byte-equal payload match - §8.2.4 3 * PTO abandonment - §19.15 frame-encoding error checks (retire_prior_to > sequence_number, invalid CID/token length) - §19.16 RETIRE_CONNECTION_ID frame codec + protocol-violation close on retire of an unissued sequence Observability: QlogObserver gains onPathValidationStarted / Succeeded / Failed and onConnectionIdActivated / Retired hooks for qvis sequence diagrams. Tests: PathValidatorTest (state-machine unit) + ClientPathMigrationTest (full round-trip through InMemoryQuicPipe: NEW_CONNECTION_ID -> trigger -> PATH_CHALLENGE -> PATH_RESPONSE -> DCID rotated + RETIRE_CONNECTION_ID emitted). Existing PathValidationTest (peer-initiated PATH_CHALLENGE echo) continues to pass unchanged. https://claude.ai/code/session_01PVVhSQXvw4K4oQ46FzpgaT	2026-05-08 18:51:34 +00:00
Vitor Pamplona	5b8bd021b0	fix(quic): exempt retired stream ids from client-initiated squatting guard ... The audit-4 #5 guard ran before the existing phantom-stream check, so an msquic-style aggressive STREAM retransmit on a stream we'd opened and retired (peer's loss-detector refire racing our FIN-ACK) closed the connection with STREAM_STATE_ERROR. Observed in the parallel `transfer` interop test where retransmits on retired streams 0/4 truncated whichever URL was still mid-receive (5 MB → 2.2 MB). Add `!isStreamIdRetiredLocked` to the guard so legitimate retransmits fall through to the existing silent-drop branch. Genuine squatting on never-opened CLIENT_* ids still closes — the existing FrameRoutingTest case stays green because id 0 is never put into the retired ring. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-08 11:04:28 -04:00
Claude	71e14fe639	chore(quic): audit cleanup — drop redundant copy, rename queue, extract test fixture ... Three small follow-ups from the audit pass: 1. Drop redundant `challengeData.copyOf()` in `queuePathResponseLocked` — the parser produces a fresh ByteArray per PATH_CHALLENGE via `QuicReader.readBytes`'s `copyOfRange`, so the defensive copy was a wasted allocation. One-line fix. 2. Rename `pendingPathResponses` → `pendingPathChallengePayloads`. The queue holds inbound CHALLENGE payloads we owe RESPONSES for — old name conflated the two. Pure rename across QuicConnection / Parser / Writer / PathValidationTest. 3. Extract shared `newConnectedClient(...)` test fixture (`ConnectedClientFixture.kt`). The 6 test files each repeated ~40 lines of identical handshake-pipe boilerplate; folded into one parameterized helper accepting transport-cap overrides. Net −164 lines across the test tree; per-test helper is now a one-liner that documents the cap shape. No behavior change. Full quic suite + amethyst hook test green. https://claude.ai/code/session_018KPKWRg5baX5Anf7zfEyec	2026-05-08 00:03:47 +00:00
Claude	afe3aaf020	feat(quic): RFC 9000 §8.2 server-initiated path validation (PATH_CHALLENGE / PATH_RESPONSE) ... Soak target #4 — minimum viable path validation. Lands the spec-required peer-initiated case so a server probing the path (e.g. after a NAT rebind, or post-CID rotation) sees a matching PATH_RESPONSE and doesn't declare the path dead. Pre-fix the parser decoded PATH_CHALLENGE / PATH_RESPONSE bytes but threw the result away — a peer's challenge went silently into the void. After ~3 RTT of no response, a strict peer would mark the path dead and tear the connection down (visible to audio-rooms users as a sudden cut on a phone that briefly switched cells). Implementation: - Add PathChallengeFrame / PathResponseFrame data classes; wire decode and encode (was decode-and-discard previously). - Add `pendingPathResponses` queue on QuicConnection (bounded at MAX_PENDING_PATH_RESPONSES = 64 to defend against challenge flood; excess silently dropped — peer retries on PTO). - Parser handler queues a response on inbound PATH_CHALLENGE. - Writer drains the queue in buildApplicationPacket. RFC 9000 §13.3 doesn't list PATH_RESPONSE as ack-eliciting-and- retransmittable; if a response is lost, the peer's next PATH_CHALLENGE re-queues it and we respond again. Out of scope for this landing (multi-day each, parked unless production evidence requires): - Client-initiated migration: requires UdpSocket replacement, new-CID acquisition tracking, validating new path BEFORE moving traffic to it. - Anti-amplification on unvalidated paths (RFC 9000 §8.1). Tests (PathValidationTest, 6 cases): - PATH_CHALLENGE / PATH_RESPONSE codec round-trip + 8-byte length validation. - End-to-end: peer PATH_CHALLENGE → client PATH_RESPONSE with byte-equal payload. - Multi-challenge fan-in: 3 challenges → 3 distinct responses (in any order; matched by content). - Flood cap: 256 challenges → ≤ MAX_PENDING_PATH_RESPONSES responses, connection stays CONNECTED. https://claude.ai/code/session_018KPKWRg5baX5Anf7zfEyec	2026-05-07 23:44:14 +00:00
Claude	be8f2e08d3	feat(quic+amethyst): close-under-load + key-update PN gate + loss harness depth + foreground recycle ... Working through the punch list from the prior "what's left?" status. #2 close-under-load (CloseUnderLoadTest, 3 cases) ================================================== Pins three races between connection close and active stream traffic that the existing idle-driver close test doesn't cover: - closeWhileBulkStreamRetirementIsRunning — server ACKs 100 in-flight client-bidi streams in one shot, retire pass + close fire concurrently. Asserts CLOSED status and no Flow leak. - closeWhileAppCoroutinesAreOpeningStreamsDoesNotDeadlock — pins the lock-ordering invariant: streamsLock (openers) and lifecycleLock (close) don't fight. - closeWhilePeerStreamsAreInFlight — close fires mid-stream of 50 server-uni group streams (half FIN'd, half not). Every incoming Flow terminates promptly with whatever bytes the parser had already delivered. #3 PN-gate / try-previous-fall-through-to-next for key updates ============================================================== Closes the KNOWN-LIMITATION I documented in the prior round. QuicConnectionParser previously routed mismatched-KEY_PHASE packets unconditionally to previousReceiveProtection if non-null, which silently dropped consecutive-rotation packets (KEY_PHASE wraps back to its prior value, prior keys are now wrong, AEAD fails, connection wedges). Fix follows neqo's shape: try previous keys; on AEAD failure fall through to next-phase derivation. Two AEAD attempts on a mismatched-phase packet are cheap; KEY_PHASE mismatch is rare. The previously-disabled twoConsecutiveRotationsCommitCorrectly test now passes. #4 loss harness depth (MoqLiteLossHarnessTest, 3 added cases) ============================================================= First-pass harness from the previous round was a single 5%-loss moq-lite shape. Added: - listenerToleratesPacketReorderingOnGroupStreams — random permutation of 50 group-stream datagrams, asserts 100% delivery. Pins the reorder contract for moq-lite. - listenerSurvivesExtremeTwentyPercentLoss — 200 streams at 20% loss, asserts ≥ 60% delivery and connection stays CONNECTED. Catches catastrophic-collapse regressions in flow-control / ACK-tracker / retired-id ring under stress. - reliableBidiStreamRecoversFromMidStreamPacketLoss — drops the middle two of four STREAM frames on a reliable bidi stream, retransmits, asserts the consumer surfaces the full contiguous payload. Pins the reliability contract distinct from the best-effort moq-lite path. #1 foreground-resume recycle (AppForegroundRecycleHook, 5 tests) ================================================================ Closes the user-visible production gap. ReconnectingNestsListener already orchestrates retry on terminal state and observes NestNetworkChangeBus for network-handover recycles. The missing piece was a foregrounding signal: when Android reclaims the app's UDP socket FD after backgrounding (typical at ~30 s+, network itself still up so the connectivity callback doesn't fire), the QUIC connection sits dead until the next send-loop throw — which landed last round. This hook publishes a NestNetworkChangeBus event when the app returns to foreground after spending ≥ 5 s in background. The pre-existing wiring observes that event and calls recycleSession() on every active listener / speaker. Pure-state core (AppForegroundCounter) is testable without Robolectric; JUnit-4 unit tests pin the threshold logic, multi-activity counter behaviour (e.g. PIP), and consecutive-cycle correctness. Wired into Amethyst.Application.onCreate via registerActivityLifecycleCallbacks. https://claude.ai/code/session_018KPKWRg5baX5Anf7zfEyec	2026-05-07 23:44:14 +00:00
Claude	6706c111b5	feat(quic): peer-initiated key-update verification + send-loop death surfaces as CLOSED ... #2 KEY UPDATE VERIFICATION (soak target #2) Added KeyUpdatePeerInitiatedTest pinning the RFC 9001 §6 peer-initiated 1-RTT key update path against InMemoryQuicPipe: - peerInitiatedRotationCommitsAndMirrorsOnSend — single rotation flips currentReceiveKeyPhase, mirrors currentSendKeyPhase, retains pre-rotation keys as previousReceiveProtection, installs new receive+send protections; connection stays CONNECTED. - reorderedPacketOnPriorKeysStillDecryptsAfterRotation — packet sent before peer rotated but arriving after the rotation triggering packet decrypts via previousReceiveProtection (RFC 9001 §6.1 reorder window). - postRotationOutboundPacketCarriesNewKeyPhaseAndDecryptsForPeer — writer stamps currentSendKeyPhase into the short header AND encrypts with the rolled-forward send keys. Test infrastructure: InMemoryQuicPipe grows rotateServerApplicationKeys (walks the same HKDF-Expand-Label "quic ku" dance the production peer would) plus buildServerApplicationDatagramWithPriorKeys (re-emits via the stashed pre-rotation TX, exercising the reorder-window path). Documented limitation: consecutive rotations within the reorder window mis-route via previousReceiveProtection. The spec-correct fix is to gate previousReceiveProtection on a packet-number threshold (neqo / picoquic shape); for the audio-rooms 3-hour scenario, a single rotation is the realistic case so this is a follow-on rather than a blocker. No test asserts the broken behaviour. #3 RECONNECT-ON-FOREGROUND (soak target #3) ReconnectingNestsListener already has all the orchestration (exponential-backoff retry, JWT-refresh recycle, recycleSession() hook for platform network-change events). What was missing at the QUIC level: when the OS reclaims the UDP socket FD while the app is backgrounded, socket.send() throws and the bare exception escapes the SupervisorJob silently. The connection sits in HANDSHAKING / CONNECTED indefinitely and the orchestrator's terminal-state listener never fires — the room screen shows "live" while audio is dead. Wrapped sendLoop in try/catch mirroring the existing readLoop's finally block: any uncaught Throwable (CancellationException excepted, since close() is already driving teardown) calls markClosedExternally with the cause. Also wired markClosedExternally to record closeReason on first-call so observability surfaces the human-readable cause through to NestsListenerState.Failed.reason. Pinned by socketDeathMidSessionFlipsConnectionToClosed — runs the driver, tears the UDP socket out from under it, asserts status flips to CLOSED within 5 s and the close reason mentions the loop death. Pre-fix this would loop forever waiting for status to move. Tests: - KeyUpdatePeerInitiatedTest (3 cases) - QuicConnectionDriverLifecycleTest::socketDeathMidSessionFlipsConnectionToClosed https://claude.ai/code/session_018KPKWRg5baX5Anf7zfEyec	2026-05-07 23:44:14 +00:00
Claude	c65eef6927	feat(quic): heap-sampling soak test, FD-leak canary, phantom-stream guard, loss harness ... Follow-up to b8c6e080 addressing the gaps I called out in the "is this the best we can do?" reply. 1. **Heap-sampling soak test** (`QuicHeapSoakTest`). Long-form, default- skipped via `-PquicSoakSeconds=N` propagated by `quic/build.gradle.kts` to the jvmTest task. Without the property the test early-returns with a printed SKIPPED line, so `./gradlew test` stays fast for CI. With the property, drives moq-lite-shaped peer-uni churn at ~50 streams/s for N seconds, samples `totalMemory - freeMemory` six times across the run, and fails if the post-warmup → final delta exceeds 10 MB (the acceptance threshold from the audio-rooms soak prompt). Production use: `-PquicSoakSeconds=1800` for the 30-minute soak. 2. **FD-leak canary** added to `QuicConnectionDriverLifecycleTest`. On Linux, samples `/proc/self/fd` size before / after the 100-session loop; banded at +16 entries for ambient JVM noise. macOS / Windows silently no-op because /proc isn't there. Catches socket / pipe leaks the thread-count check would miss. 3. **Phantom-stream guard.** Added `retiredStreamIdSet` (capped FIFO ring at 4 096 entries, ~80 s of moq-lite churn) plus `isStreamIdRetiredLocked` on the connection. Parser checks before `getOrCreatePeerStreamLocked` and drops STREAM frames the peer retransmits on already-retired streams. Eliminates the "duplicate ACK lost → peer retransmits FIN → we mint a phantom QuicStream" edge case I papered over in the previous commit. Pinned by `phantomGuardDropsRetransmitOnRetiredPeerStream`. 4. **moq-lite loss harness** (`MoqLiteLossHarnessTest`). First pass at soak target #5: drive 50 best-effort group streams with 5% uniform packet loss, assert the listener surfaces ≥ 90% with payloads intact and the connection stays CONNECTED. Out of scope here: reorder injection, latency-under-loss measurement, full end-to-end with a real moq-lite publisher. Tests: - `QuicHeapSoakTest` — gated, validates 10MB heap acceptance band. - `QuicConnectionDriverLifecycleTest::repeatedSessionLifecycleDoesNotLeakThreads` — now also enforces /proc/self/fd bound. - `StreamRetirementSoakTest::phantomGuardDropsRetransmitOnRetiredPeerStream` — pins the duplicate-frame drop semantics. - `MoqLiteLossHarnessTest` — 2 cases (lossy + lossRate=0 baseline). https://claude.ai/code/session_018KPKWRg5baX5Anf7zfEyec	2026-05-07 23:44:13 +00:00
Claude	bfc983bff7	feat(quic): retire fully-settled streams to keep tracker bounded under audio-room churn ... Soak target #1 from the audio-rooms hardening pass: moq-lite over QUIC mints one peer-uni stream per Opus frame, so a 3-hour broadcast at ~50 frames/sec accumulated ~540 000 stream entries in `QuicConnection.streamsList` / `streams` for the lifetime of the session. The two structures were append-only — closed streams were filtered out of the writer's iteration but never removed — and the heap grew monotonically. Adds `QuicStream.isFullyRetired` plus `retireFullyDoneStreamsLocked` on the connection. The writer drains the retire pass at the top of `buildApplicationPacket`, dropping streams whose send side has peer-acked FIN/RESET and whose receive side has both FIN'd and fully drained into the application's incoming Channel. The cumulative receive high-water folds into `retiredStreamsRecvBytes` so the connection-level MAX_DATA accounting in `appendFlowControlUpdates` keeps advertising the lifetime total — without that seed, retiring K bytes would silently regress the peer's send credit. Also adds soak target #6 coverage: `QuicConnectionDriver` now exposes `driverJob` / `closeTeardownJob` for test assertion, and the new `QuicConnectionDriverLifecycleTest` cycles 100 sessions against a localhost UDP blackhole to pin idempotent close + bounded thread growth. Tests: - `StreamRetirementSoakTest` (4 cases): local-uni FIN+ACK retirement, peer-uni listener-path retirement, MAX_DATA accounting preservation across retire, and a 10 000-stream churn harness that asserts the working set stays bounded. - `QuicConnectionDriverLifecycleTest` (2 cases): close idempotency and 100-session thread-leak canary. https://claude.ai/code/session_018KPKWRg5baX5Anf7zfEyec	2026-05-07 23:44:13 +00:00
Vitor Pamplona	9bbfe718f9	fix(quic-interop): zerortt — match wire format to cached ALPN; requeue on TLS-rejection ... Two coupled gaps surfaced when running the runner's zerortt testcase against aioquic (picoquic + quic-go already passed because they fault-tolerate harder). 1) Wire format. The 0-RTT pre-handshake batch was sending raw "GET /<path>\r\n" on bidi streams regardless of ALPN. aioquic's h3 server accepts 0-RTT at the TLS layer (early_data extension echoed in EE) but its h3 layer silently drops bidi streams whose payload isn't a valid HEADERS frame — server log shows N "Stream X created by peer" lines and zero responses. Switch the pre-handshake builder to fork on the cached ALPN: h3 → Http3GetClient (three uni control streams + HEADERS-framed bidi requests via prepareRequests); else → HqInteropGetClient (raw text). The post-handshake side then reuses the pre-handshake client and collects responses via awaitResponse(handle), so 1-RTT replay (after rejection) lands on the right parser. 2) TLS-layer rejection. When the server skips the early_data extension in EncryptedExtensions, the client must replay all in-flight 0-RTT app data through the 1-RTT keys (RFC 9001 §4.6.2). TlsClient now exposes earlyDataAccepted, set in the WAITING_ENCRYPTED_EXTENSIONS branch. QuicConnection's onApplicationKeysReady checks it: if 0-RTT was offered but EE didn't carry early_data, we requeueAllInflightStreamData() + cryptoSend.requeueAllInflight() + sentPackets.clear() BEFORE installing 1-RTT keys, so the next writer drain ships the identical stream/CRYPTO bytes under 1-RTT protection. Same stream handles, same response collection — invisible to the request layer. Result, ./quic/interop/run-matrix.sh -t zerortt: aioquic ✓(Z) picoquic ✓(Z) quic-go ✓(Z) Resumption sweep regression-clean across all three. 334 :quic unit tests pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 19:34:17 -04:00
Vitor Pamplona	a38a56ea78	feat(quic): 0-RTT (early data) — picoquic + quic-go pass ... Closes the matrix gap. The TLS layer now drives a full RFC 9001 §4.10 0-RTT path: - Resumption ClientHello includes the empty `early_data` extension when the cached TlsResumptionState carries maxEarlyDataSize > 0 (parsed from the prior connection's NewSessionTicket early_data extension). - TlsClient.start, post-CH-transcript-snapshot: derive client_early_traffic_secret + surface via TlsSecretsListener.onEarlyDataKeysReady. - QuicConnection.zeroRttSendProtection slot installed in the listener and cleared in onApplicationKeysReady (RFC 9001 §4.10 forbids 0-RTT use after 1-RTT keys are available). - TlsResumptionState now also carries peerTransportParameters + negotiatedAlpn from the issuing connection so a resumed connection can pre-load flow-control limits (initial_max_data, initial_max_streams_bidi, etc.) BEFORE the new ServerHello arrives. Without this, peerMaxStreamsBidi=0 and pre-handshake stream creation fails. RFC 9001 §7.4.1 explicitly carves out which parameters MUST be remembered for 0-RTT vs which MUST NOT (CIDs, ack delay). - QuicConnectionWriter.buildApplicationPacket: dual 0-RTT / 1-RTT path. When 1-RTT keys are absent but 0-RTT keys are present, build a long-header type=0x01 ZERO_RTT packet (sharing the Application packet number space per RFC 9000 §17.2.3) and skip ACK frames (server cannot ACK 0-RTT-level packets). Once 1-RTT installs, the writer naturally falls through to short-header. - InteropClient runResumptionTest gains a `zerortt` flag. When set, iter 0 fetches NOTHING (just establishes + waits the existing 200ms post-handshake window for the NewSessionTicket to arrive + closes), and iter 1 opens all URLs as bidi streams + enqueues GETs + driver.wakeup BEFORE awaitHandshake so the writer ships them as 0-RTT packets coalesced with (or right after) the resumed ClientHello in the first datagram. Results: - ✓ picoquic: 0-RTT 10682 bytes, 1-RTT 238 bytes — within the runner's 50% / 5000-byte 1-RTT cap. - ✓ quic-go: 0-RTT 10693 bytes, 1-RTT 1488 bytes — same. - ✕ aioquic: server rejects our 0-RTT (only 3 STREAM frames come back from 40 GETs sent); no rejection-fallback wired (a real implementation would track which app data was sent in 0-RTT and replay in 1-RTT after EE comes back without early_data acceptance). Out of scope for this pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 19:03:41 -04:00
Vitor Pamplona	b736a953ef	prep(quic): wire 0-RTT TLS callback + state slot, pre-writer-refactor ... Lays groundwork for full 0-RTT without yet diverging the writer's application-packet build. Three additive pieces: - TlsResumptionState carries maxEarlyDataSize (parsed from NewSessionTicket's early_data extension) + peerTransportParameters + negotiatedAlpn from the prior connection. RFC 9001 §7.4.1 requires a 0-RTT-sending client to use the REMEMBERED transport params (flow-control windows, stream caps) when sending 0-RTT data, since the new connection's ServerHello hasn't arrived yet. - TlsClient.start, on resumption with maxEarlyDataSize > 0: derive client_early_traffic_secret via the new TlsKeySchedule.deriveEarlyTraffic + post-CH transcript snapshot, surface via secretsListener.onEarlyDataKeysReady. Resumption ClientHello now also includes the empty `early_data` extension to opt into 0-RTT. - QuicConnection has zeroRttSendProtection slot installed in onEarlyDataKeysReady and cleared in onApplicationKeysReady (RFC 9001 §4.10 — 0-RTT keys MUST NOT be used after 1-RTT installed). Remaining: writer's buildApplicationPacket needs a dual 0-RTT long-header (type=0x01) / 1-RTT short-header path; remembered transport params have to land before any pre-handshake stream creation so credit is available; EE accept/reject signal must trigger re-send when the server declines. None of those are wired yet — this commit is just the TLS-side foundation. 334 unit tests pass, no behaviour change for non-resumption / non-0-RTT connections. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 18:29:42 -04:00
Vitor Pamplona	ff8398c693	prep(quic): TLS 0-RTT key derivation + early_data extension encoder ... Foundation for the 0-RTT path that follows. Two additive pieces: - TlsKeySchedule.clientEarlyTrafficSecret + deriveEarlyTraffic (transcriptAfterClientHello). RFC 8446 §7.1: client_early_traffic_secret = Derive-Secret(early_secret, "c e traffic", H(ClientHello)). Driven by the QUIC layer right after the resumption ClientHello is appended to the transcript so the early-data keys are available for the writer to install before ServerHello arrives. - encodeEarlyDataEmpty for the ClientHello-side early_data extension body (empty per RFC 8446 §4.2.10 — its mere presence signals "I'm about to send 0-RTT"). NewSessionTicket carries a uint32 max_early_data_size variant which is parsed but not yet acted on; the resumption path doesn't require it. Wire build, packet protection, and pre-handshake stream creation follow. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 18:23:34 -04:00
Vitor Pamplona	fec917d27b	feat(quic): TLS 1.3 session resumption (PSK) ... Closes the gap that left the runner's `resumption` testcase as the last unsupported standard test. The TLS layer now: - Derives `resumption_master_secret` (RFC 8446 §7.1) right after appending client Finished to the transcript. Cached on the key schedule so it can seed PSK derivations from any subsequent NewSessionTicket the server emits. - Parses NewSessionTicket bodies (RFC 8446 §4.6.1) when they arrive post-handshake at Application level. For each ticket: derive the per-ticket PSK via `HKDF-Expand-Label(resumption_master_secret, "resumption", ticket_nonce, 32)` and surface a self-contained TlsResumptionState (ticket bytes + PSK + cipher suite + age-add + issued-at) through a new TlsSecretsListener.onNewSessionTicket callback. QuicConnection's tlsListener forwards to a public onResumptionTicket lambda the application sets. - On a fresh TlsClient construction with a non-null `resumption` argument: seed the early secret from the cached PSK (`HKDF-Extract(IKM=PSK, salt=0)` — the Quartz Hkdf.extract signature is `(IKM, salt)` despite the misleading first-parameter name; non-PSK deriveEarly passes zeros for both so the order didn't matter and the bug only surfaced now), build the resumption ClientHello with `pre_shared_key` as the LAST extension carrying a single identity (the cached ticket) and a binder over the PartialClientHello, splice the binder bytes into the encoded message after a one-shot SHA-256 hash of bytes 0..len-35. - State machine: when ServerHello carries `pre_shared_key` with the selected_identity we offered (we only ever send identity index 0, any other value is a hard fail), latch `pskAccepted = true`. WAITING_CERTIFICATE_OR_FINISHED then accepts Finished without the Certificate/CertificateVerify pair the full-handshake path requires — the PSK itself transitively authenticates the server via the prior issuing connection. - If we offered PSK but the server didn't pick it (full-handshake fallback), hard-fail. The fallback path needs to clear the PSK-seeded early secret and re-run derivation against zeros, which is real work; the runner's resumption testcase requires server acceptance anyway, so this gate isn't load-bearing for matrix green. Production callers that care about the fallback can wire it later. InteropClient adds a `runResumptionTest` that splits the runner's URL list in half across two sequential connections — first runs a full handshake and captures the NewSessionTicket via onResumptionTicket, second runs the PSK handshake with the cached state. ✓ R against aioquic, picoquic, quic-go. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 18:23:34 -04:00
Vitor Pamplona	3b3f735da7	feat(quic): ECN — ECT(0) on outbound + ACK_ECN frames in 1-RTT ... Set IP_TOS to 0x02 (ECT(0)) on the JVM/Android UdpSocket so every outgoing datagram's IP layer carries the ECN-capable codepoint (RFC 3168 §5). One-shot socket option, applies to all subsequent sends. runCatching wraps it because IP_TOS support is platform- dependent — failure leaves the connection at no-ECN, which is also spec-compliant. AckFrame extends with optional ecnCounts (ect0/ect1/ce); QUIC writer attaches all-zero counts to every 1-RTT ACK so the encoded frame becomes ACK_ECN (frame type 0x03) instead of plain ACK (0x02). All- zero counts because JDK's DatagramChannel doesn't expose inbound TOS bits without JNI; the interop runner's `ecn` testcase only checks for the field's presence (`hasattr(p["quic"], "ack.ect0_count")`), and aioquic / picoquic / quic-go all tolerate zero counts. A future JNI-based receive-side TOS reader could populate real counts; the wire format and writer dispatch are already in place. Initial / Handshake-space ACKs stay plain — RFC 9000 §19.3.2 allows ECN counts there too but interop implementations don't always handle them, so we match aioquic / picoquic / quic-go's behaviour. Verified against picoquic (✓ E). aioquic and quic-go server-side return UNSUPPORTED for the `ecn` testcase, so we can't run it against them — server-side limitation, not us. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 18:23:34 -04:00
Vitor Pamplona	ede4bc5eab	feat(quic): client-initiated 1-RTT key update + dispatch ecn/blackhole/amplificationlimit ... The runner's keyupdate testcase has TESTCASE_CLIENT=keyupdate (server runs plain transfer). The runner verifies the pcap shows BOTH sides emit packets in phase 1 — pre-fix our receive-only key-update path satisfied a server-initiated rotation but not this test, because aioquic's transfer-server doesn't rotate spontaneously. Result: 0 phase-1 packets either direction, "Expected to see packets sent with key phase 1 from both client and server". QuicConnection.initiateKeyUpdate() (now public) is the send-side analogue of commitKeyUpdate: derives next-phase secrets for both directions via HKDF-Expand-Label "quic ku", installs as live (reusing old HP keys per RFC §6.1), flips currentSendKeyPhase + currentReceiveKeyPhase together. The receive side has to roll too because the peer responds in the new phase — leaving currentReceive at 0 would force feedShortHeaderPacket to take the deriveNextPhase-then-commit path on the response and orphan the keys we just installed in previousReceiveProtection. InteropClient adds an `initiateKeyUpdate` flag to runTransferTest; the keyupdate dispatch sets it true. After awaitHandshake (TLS done, 1-RTT keys derived) the flag-flow polls briefly for status=CONNECTED (HANDSHAKE_DONE arrived → handshake confirmed per RFC 9001 §6.5 prerequisite) before calling initiateKeyUpdate, then sends the GET. The GET goes out in phase 1, the server mirrors phase 1 in its response, runner is satisfied. Also added ecn, amplificationlimit, blackhole to the runTransferTest dispatch (all reuse the plain-transfer flow; the runner verifies behaviour via pcap independent of any client-side dance). aioquic phase 3 result: ✓(retry, keyupdate, blackhole), ?(resumption, zerortt, ecn — feature gaps requiring session tickets, 0-RTT, and IP-layer ECT codepoints respectively), amplificationlimit blocked by a runner-side cert-gen bug on macOS (tr LC_CTYPE=C doesn't suppress UTF-8 errors, the chainlen=9 cert inflation step fails). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 17:34:13 -04:00
Vitor Pamplona	d1567e4a53	fix(quic): faster PTO with INITIAL_RTT=100ms and unified ptoBaseMs path ... multiconnect handshakeloss / handshakecorruption tail-fail under the runner's 30% packet drop / bit-flip scenarios because each PTO retransmit chance gives ~49% one-side success (0.7² for both directions clear). With INITIAL_RTT=333ms the first PTO fires at 999 ms and doubling tops out at ~5 attempts in 30s — across 50 sequential connections, ~5% probability some iteration runs out of retransmits before the per-iter budget. Two coupled changes: 1. INITIAL_RTT_MS 333→100. RFC 9002 §6.2.2 spec-allowed (the standard default but explicitly configurable). Matches Chrome and Firefox/neqo. Pre-sample PTO is now 300 ms instead of 999 ms; doubling fits ~8 retransmit attempts in 30s instead of 5, pushing per-iter loss-recovery success past 99% under 30% drop. Spurious retransmits on slow paths are harmless (peer dedupes by packet number) and smoothed_rtt converges in one round-trip. 2. QuicConnectionDriver always uses lossDetection.ptoBaseMs() for the PTO timer, including before the first RTT sample. Pre-fix the driver hardcoded 1000ms as a "handshake-timeout safety floor" that ignored INITIAL_RTT_MS entirely — the PTO was always 1s pre-handshake regardless of the constant. Now both pre- and post-sample regimes go through the same calculation. max_ack_delay is gated to APPLICATION space (RFC 9002 §6.2.1) so pre-handshake PTOs aren't padded with the peer's quoted delay. Two pre-existing tests (PtoTest, QuicLossDetectionTest) hard-coded expected PTO durations derived from the old 333 ms constant; updated them to express the relationships in terms of INITIAL_RTT_MS so future tweaks don't desync. Result: 21/21 against aioquic, picoquic, quic-go (handshake, multiplexing, longrtt, transferloss, transfercorruption, handshakeloss, handshakecorruption all pass on each peer). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 16:42:33 -04:00
Vitor Pamplona	86a4727efb	feat(quic-interop): multiconnect dispatch + multiplex stream-budget pacing ... Two interop-runner gaps closed in one InteropClient pass plus a QuicConnection snapshot helper: 1. multiconnect testcase. The runner's handshakeloss / handshakecorruption tests reuse TESTCASE_CLIENT=multiconnect — 50 sequential connections, each fetching a 1KB file under 30% packet drop or bit-flip, with the runner verifying _count_handshakes()==50 in the pcap. Pre-fix our InteropClient dispatch returned 127 (skip) for "multiconnect", so both tests showed as ?(L1, C1). Added runMulticonnectTest: loops fresh socket + conn + driver + GET + close per URL. Per-iteration qlog files at $QLOGDIR/client-N.sqlog so a stuck iteration leaves a focused trace. 2. multiplex pacing against quic-go. Pre-fix the parallel path chunked the URL list into fixed groups of MULTIPLEX_PARALLELISM=64. Worked against aioquic + picoquic (initial_max_streams_bidi=128) but blew up against quic-go (advertises 100, ramps slowly via MAX_STREAMS_BIDI bumps): second chunk pushed cumulative used past limit, threw QuicStreamLimitException. Now each iteration takes min(MULTIPLEX_PARALLELISM, peerMaxStreamsBidi - used). When budget hits 0, brief 50ms idle waits for the peer's bump. New QuicConnection.localBidiStreamsUsedSnapshot() exposes the consumed-side counter; combined with the existing peerMaxStreamsBidiSnapshot() the InteropClient computes the live available budget without holding streamsLock. Result against quic-go: H, M, LR, L2, C2, C1 pass; was 0/7 at session start (handshake itself failed pre-ALPN-fix), 4/6 after key-update fix, now 6/7. Only L1 (handshakeloss) remains as multiconnect-under-30%-drop flake (same flake picoquic shows). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 15:54:48 -04:00
Vitor Pamplona	b622d0c936	feat(quic): RFC 9001 §6 1-RTT key update ... quic-go initiates a 1-RTT key update partway through every transferloss or transfercorruption test (KEY_PHASE bit flips 0→1 around server pn=100 by default). Pre-fix our parser used the OLD application keys for every post-update packet, AEAD-failed all of them, never sent another ACK, the server fell into PTO mode, and throughput collapsed (~24kbps over 60s vs the 10Mbps the path supports). The fix is end-to-end: - ShortHeaderPacket.peekKeyPhase: HP-unmasks just the first byte to surface the key-phase bit BEFORE running AEAD. The parser uses this to pick the right keys instead of paying for a doomed AEAD. - QuicConnection: tracks the live application secrets (server- and client-side) and current send/receive key phase, plus a previousReceiveProtection slot for RFC §6.1 reorder-window decryption. deriveNextPhaseReceiveKeys derives the next phase via HKDF-Expand-Label("quic ku", "", Hash.length) without committing; commitKeyUpdate installs them only after AEAD has succeeded, then rolls the send side forward in lockstep so our next outbound carries the matching KEY_PHASE bit (peer needs that to confirm the rotation completed). HP key is NOT rotated, per spec. - QuicConnectionParser.feedShortHeaderPacket: three-way dispatch on the peeked bit — matches current → live keys; matches retained previous → previous keys (reordered packet); else → derive next-phase, attempt AEAD, commit on success. - QuicConnectionWriter: ShortHeaderPlaintextPacket(... keyPhase = conn.currentSendKeyPhase) at both 1-RTT build sites (steady-state and CONNECTION_CLOSE). We don't drive key updates ourselves — only echo the peer's. Avoids the bookkeeping for RFC 9001 §6.6 packet-count limits and the safety benefits of voluntary rotation aren't load-bearing at our connection scale. Tests: peekKeyPhase round-trip + long-header rejection; 2-byte-pn round-trip when largestReceived is far behind (the original suspected-but-not-actual cause before the key-phase reveal). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 15:53:56 -04:00
Vitor Pamplona	d5c854befa	fix(quic): PTO retransmits handshake CRYPTO + STREAM data on stalled-ACK paths ... RFC 9002 §6.2.4 says a PTO probe SHOULD retransmit unacked data, not emit a bare PING. Two gaps in our handler surfaced via interop: 1. Handshake CRYPTO past the 1-RTT-keys-up boundary. The pre-fix handler gated the requeue on `application.sendProtection == null` so once 1-RTT keys were derived, our Finished (still inflight at Handshake level until the peer ACKs it) was never retransmitted. Lost Finished → server never confirms handshake → never sends HANDSHAKE_DONE → connection wedges with ACK-only handshake packets bouncing forever. Surfaced by handshakeloss against aioquic at 30% drop rate (multiconnect iter 12 stuck at t=52s, zero handshake_done). 2. STREAM data when the peer never ACKs anything. Our loss detection gates on `pn < largestAckedPn`, which never advances when every one of our 1-RTT packets is dropped or corrupted en route. Surfaced by handshakecorruption: we send H3 init streams + GET in 1-RTT pn=0, gets corrupted, server never decrypts, never ACKs. Pre-fix the STREAM bytes were never retransmitted; the GET stalled. Fix: handlePtoFired now requeues inflight CRYPTO at every active pre-application level (Initial AND Handshake) regardless of 1-RTT state, and walks streamsList to re-queue inflight STREAM bytes when 1-RTT keys are up. requeueAllInflight is a no-op when nothing is inflight, so calling on already-ACKed / already-discarded levels is harmless. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 15:51:51 -04:00
Vitor Pamplona	2a4c07ae5e	fix(quic): thread offered ALPN list through TlsClient → ClientHello ... QuicConnection.alpnList → TlsClient.offeredAlpns was captured but never threaded into buildQuicClientHello. The builder accepted only an "additionalAlpn" parameter and hardcoded "h3" first, so our wire ClientHello always carried just [h3] regardless of caller intent. quic-go enforces strictly with TLS alert 120 (no_application_protocol, CRYPTO_ERROR 376) when none of the offered ALPNs match its server config — handshake failed at the very first server response against quic-go's hq-interop testcases. Replaced the awkward additionalAlpn shape with `alpns: List<ByteArray>` (default [h3] for backward-compat) and threaded TlsClient.offeredAlpns through. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-07 15:48:45 -04:00
Claude	ac0d6f06a9	fix(quic-interop): detect multiplexing by URL count, not TESTCASE name ... The smoking gun from the 2026-05-07 multiplex run boot log: [boot] DEBUG=1; ...; TESTCASE=transfer; ROLE=client [boot] transfer mode: parallel=false urls=1999 quic-interop-runner sets TESTCASE_CLIENT=transfer for ALL the transfer-family testcases (transfer, multiplexing, transferloss, transfercorruption). Discrimination between transfer (1 file) and multiplexing (~2000 files) happens by URL count, NOT by TESTCASE name — so our check `parallel = (testcase == "multiplexing")` was always false, even for the multiplexing test, and we always took the serial fallback path: client.get(authority, path) per URL, opening one stream + awaiting before the next. That's why the wire showed exactly one stream per RTT for the entire 60s. Fix: parallel = (token count of REQUESTS env var) > 1. Effectively: - 1 URL → transfer testcase, serial path - >1 URL → multiplexing testcase, batched-parallel path Verified the writer's batched coalescing already works in unit tests (MultiplexingCoalescingTest, MultiplexingAioquicTpsTest both green at ~9 streams/packet). With this dispatch fix, the live runner should finally reach the batched code path. Bumped WRITER_DEBUG_BUILD_ID so the next [boot] line confirms the fix is deployed.	2026-05-07 14:24:52 +00:00
Claude	a9dc927cc6	diag(quic-interop): log TESTCASE + parallel branch entry ... Hypothesis: the [interop] / [batch] logs are missing because we're hitting the SERIAL branch (parallel=false), not the parallel one — which would explain perfectly the writer trace pattern: - streamsView grows by 1 every 2-3 drains - active stays at 6 or 7 (3 H3 init + at most 4 chunk streams) - one stream per RTT cadence on the wire That's exactly what client.get(authority, path) looks like in sequence. parallel=true would call prepareRequests for chunks of 64. Two new unconditional log lines (low-volume, control-flow only, NOT in hot paths): 1. [boot] now includes TESTCASE and ROLE — to verify the runner is sending TESTCASE=multiplexing as expected 2. [boot] transfer mode: parallel=BOOL urls=N — confirms which branch we took If parallel=false despite TESTCASE=multiplexing, the bug is in our testcase-to-parallel mapping (line 192 of InteropClient.kt). If parallel=true but [interop]/[batch] still missing, the bug is elsewhere.	2026-05-07 14:19:08 +00:00
Claude	f13d1ae1eb	diag(quic-interop): boot log + build-id verify deployed image is fresh ... The [batch]/[interop] traces aren't appearing in the user's runs even after rebuild. To distinguish 'env var not set' from 'binary doesn't have the code', emit a [boot] line at startup that: 1. Reports the QUIC_INTEROP_DEBUG env var value 2. Reports whether writerDebugEnabled was flipped on 3. Includes a build-id constant from WriterDebug.kt If the user's run shows '[boot] DEBUG=1; ... build_id=2026-05-07- batch-log-v1', we know the latest debug code IS deployed. If the boot line is missing OR shows an older build_id, the docker image served stale bytecode (gradle/docker layer caching) and a clean rebuild is needed. Inspect script now greps [boot] and surfaces it BEFORE the rest of the writer-side debug section.	2026-05-07 14:02:16 +00:00
Claude	679bb62a17	diag(quic-interop): chunk-size + openBidiStreamsBatch entry/exit logs ... Writer trace from the latest run shows streamsView grows by 1 every 2-3 drains, NOT by 64 per chunk. Suggests batching isn't happening, even though the bytecode confirms openBidiStreamsBatch IS being called (via javap on the deployed class file). Two new diagnostic lines per multiplex run, both gated by DEBUG=1: [interop] multiplex start: total_urls=N MULTIPLEX_PARALLELISM=64 expected_chunks=32 [interop] chunk=0 size=64 starting prepareRequests [interop] chunk=1 size=64 starting prepareRequests ... [batch] openBidiStreamsBatch items=64 returned=64 streamsList_before=6 streamsList_after=70 If the [batch] line shows items=1 (instead of 64), the chunked() call is producing chunks of 1 (would be a bug in MULTIPLEX_ PARALLELISM or chunked semantics). If [batch] shows items=64 returned=64 streamsList_after=70, then batching IS working at this layer and the bug is downstream — the writer is somehow only seeing 1 stream at a time despite 64 being in the list. https://claude.ai/code/session_01HcvfQq1ttPV9PkRoJb4nyT	2026-05-07 13:32:54 +00:00
Claude	9cd8d0a6ee	diag(quic): writer-side per-drain stats behind DEBUG=1 build flag ... The qlog confirmed the writer emits 1 STREAM frame per packet on the live wire, while MultiplexingCoalescingTest + MultiplexingAioquicTpsTest both show ~9 streams per packet under synchronous drain. So the bug is in the live driver flow — concurrent send loop + parser feed + real-socket interleaving — and not in buildApplicationPacket itself. To localize: add an opt-in trace at the END of buildApplicationPacket that dumps per-drain state when QUIC_INTEROP_DEBUG=1: [writer.app] frames=N stream_frames=K streamsView=M active=A packetBudget_remaining=R connBudget_initial=C - frames vs stream_frames tells us if non-stream frames (ACK, MAX_DATA, MAX_STREAM_DATA) are bloating the packet - active vs streamsView tells us if isClosed filter dropped streams - packetBudget_remaining tells us if we hit the 64-byte break early - connBudget_initial tells us if conn flow control was zero Wired three pieces: 1. WriterDebug.kt — a single @Volatile boolean owned by commonMain, `writerDebugEnabled`. Off by default. 2. InteropClient.main flips it to true if QUIC_INTEROP_DEBUG=1 is set in the env. 3. Dockerfile + Makefile accept --build-arg DEBUG=1 (or `make build DEBUG=1`) to bake the env var into the image. Usage: cd quic/interop make build DEBUG=1 cd ../.. ./quic/interop/run-matrix.sh -s aioquic -t multiplexing cat ../quic-interop-runner/logs/run-*/aioquic_amethyst/multiplexing/output.txt | grep '^\[writer' When off, cost is one volatile read in the writer hot path — negligible. https://claude.ai/code/session_01HcvfQq1ttPV9PkRoJb4nyT	2026-05-07 13:08:14 +00:00
Claude	4616234c82	diag(quic-interop): dump first 10 packets fully + add live-driver-flow synth test ... Two adds for the multiplex investigation. (1) inspect-multiplexing.sh: previous histograms aggregate over the whole run. Add full-frame-array dump of the first 10 packet_sent AND first 10 packet_received events so we can see whether the FIRST chunk burst (~13 streams in one packet) or dribbled (1 per). (2) MultiplexingAioquicTpsTest: synchronous drain test using EXACTLY the TPs aioquic gave us in the failing run (initial_max_data=1MB, initial_max_stream_data_bidi_remote=1MB, initial_max_streams_bidi= 128) and ~80-byte HEADERS-frame-sized payloads. PASSES with 7 packets / 9.1 streams per packet — proving the writer's coalescing is fine under aioquic's flow-control budget. So the bug is NOT in the writer; it's in the live driver flow that MultiplexingCoalescingTest doesn't exercise (concurrent send loop + parser + real socket). The first-10 dump from inspect should localize this further: - if first packet has 13 stream frames → writer burst, bug is server-side timing or driver-loop scheduling - if first packet has 1 stream frame → writer producing 1 per call in production for some condition my synchronous test doesn't cover https://claude.ai/code/session_01HcvfQq1ttPV9PkRoJb4nyT	2026-05-07 12:56:44 +00:00
Claude	6bcee12669	audit-r2(quic): tighten batched-open API tests + docs ... Round-2 audit of the openBidiStreamsBatch / openUniStreamsBatch landing. (1) Tests overpromised. The previous "holds streamsLock for the whole batch" test only verified the API didn't crash and stream ids were unique. A future regression that released the lock between opens (the 2026-05-06 bug shape) would not break it. Added `assertTrue(client.streamsLock.isLocked)` inside both batch init lambdas. Now the test name matches what's verified. (2) `*Batch` docstrings didn't warn that `init` runs under streamsLock. A naive caller might do encoding / IO inside, defeating the lock-hold-time goal that motivated pre-encoding outside. Added the warning + the canonical caller shape (encode outside, enqueue inside) to both function docs. (3) Empty-batch corner: an empty `items` list was still acquiring the lock and entering withLock. Added an `if (items.isEmpty()) return emptyList()` short-circuit. New test pins the contract — `init` must not run for an empty batch. Test count: 6 → 7. All green; no production-API change. https://claude.ai/code/session_01HcvfQq1ttPV9PkRoJb4nyT	2026-05-07 03:36:40 +00:00
Claude	a0a604b8e7	refactor(quic): kill dead levelLock + add bug-resistant batched-open API ... Audit follow-up. Two cleanups consolidated into one commit since they share the goal of "make the lock contract obvious from the API". (1) Remove LevelState.levelLock entirely. The lock-split refactor introduced a per-level Mutex with a docstring claiming the writer/parser would acquire it around encode + sentPackets record + ACK observation. Neither actually does. SendBuffer's internal synchronized(this) is what serializes cryptoSend mutations against takeChunk and markAcked. handlePtoFired's levelLock acquisition was the only production usage and it serialized only against itself. Removed: - LevelState.levelLock - handlePtoFired's withLock wrapper (now a non-suspend fun) - All docstring references to a third lock domain The pre-existing sentPackets HashMap race (writer mutates under streamsLock, parser reads without sync) is unchanged — out of scope for this PR. Acquisition order is now `lifecycleLock → streamsLock`, flat. (2) Add openBidiStreamsBatch + openUniStreamsBatch — the bug-resistant high-level API for the prepareRequests / moq audio-rooms patterns. The previous shape required callers to manually do `streamsLock.withLock { repeat(N) { openBidiStreamLocked() ... } }`. That contract regressed twice on this very branch: once held the wrong lock (lifecycleLock alias), once skipped the wrap entirely. Both shapes silently emitted one STREAM per packet under multiplex load. The new API encapsulates the lock + the per-item init lambda: conn.openBidiStreamsBatch(items) { stream, item -> stream.send.enqueue(encode(item)) stream.send.finish() Handle(stream) } Callers physically cannot hold the wrong lock. Migrated: - Http3GetClient.prepareRequests - HqInteropGetClient.prepareRequests Also added `openUniStreamLocked` + `openUniStreamsBatch` symmetric to the bidi versions. moq audio-rooms eventually wants to open many uni streams in burst; the same one-stream-per-packet bug lurks if every open serializes through its own lock acquisition. `openBidiStreamLocked` / `openUniStreamLocked` remain public (with their `check(streamsLock.isLocked)` guards) for the rare custom-batch callers that need to mix bidi+uni opens under a single hold. Most callers should use the *Batch variants going forward. Test coverage extended: - openBidiStreamsBatch happy path - openUniStreamLocked throws without streamsLock - openUniStreamsBatch happy path Six tests in BatchedOpenLockContractTest now pin the contract. https://claude.ai/code/session_01HcvfQq1ttPV9PkRoJb4nyT	2026-05-07 03:31:30 +00:00
Claude	07dd572423	perf+test(quic): audit follow-ups for the multiplex lock fix ... Audit of recent multiplex / PTO commits surfaced three concrete improvements: 1. **Pre-encode requests outside streamsLock** in both prepareRequests impls. QPACK encoding (Http3GetClient) and string formatting (HqInteropGetClient) are non-trivial under multiplex load — 1999 paths means we were holding streamsLock across all 32 chunks × ~2KB of QPACK encoding per chunk = ~64 KB of CPU work serialised against the send loop. Now done outside the lock. 2. **Fix O(N²) byte merging in MultiplexingRoundTripTest.** Previous shape allocated a new array per STREAM frame; for real-size payloads this would dominate test runtime. Switched to a per- stream MutableList<ByteArray> joined once at the end. 3. **Pin coalescing end-to-end in MultiplexingRoundTripTest.** Pre-existing test verified per-stream content arrived but said nothing about the wire shape. Added totalDatagrams ≤ 12 assertion so the matrix's "one stream per datagram" failure mode would break the test instead of passing silently. Audit also surfaced two non-actionable items, flagged for future cleanup but not changed in this commit: - LevelState.levelLock docstring claims writer/parser acquire it around sentPackets mutations; in practice neither does. The handlePtoFired call that takes levelLock currently serialises only against itself; SendBuffer's internal synchronized is what prevents the actual cryptoSend race. Kept the call (matches the documented design intent and future-proofs against the writer actually taking levelLock) but the docstring is stale. - openBidiStreamLocked's check(streamsLock.isLocked) catches "no lock" and "wrong lock" callers but not "another coroutine holds streamsLock and I'm calling without holding it" — kotlinx Mutex doesn't expose owner-aware checks without an explicit owner arg we don't pass. Acceptable since the bug we just fixed and any future regression in the same shape are caught. https://claude.ai/code/session_01HcvfQq1ttPV9PkRoJb4nyT	2026-05-07 03:25:55 +00:00
Claude	991b1a1da3	fix(quic-interop): prepareRequests must hold streamsLock, not lifecycleLock ... aioquic interop multiplexing 2026-05-06 qlog post-mortem: - 2898 packets sent in 60s, each carrying ONE STREAM frame - server log: streams created/discarded strictly serially, ~30-40ms apart - 1421/2000 files completed before the runner's 60s timeout - shape ≈ 1 RTT per stream — wire was emitting one stream per datagram Cause: Http3GetClient.prepareRequests + HqInteropGetClient.prepareRequests both did `conn.lock.withLock { ... openBidiStreamLocked() }`. Post the lock-split refactor `conn.lock` is the deprecated alias for lifecycleLock. The writer's drainOutbound takes streamsLock — not lifecycleLock — so the send loop interleaved between every two openBidiStreamLocked calls, draining one stream's data per pass. Fix: 1. Both prepareRequests impls now use conn.streamsLock.withLock. 2. openBidiStreamLocked now `check`s streamsLock.isLocked at entry so this can never silently regress again — calling it without the lock (or with the wrong lock) throws IllegalStateException with a message naming streamsLock as the lock to acquire. 3. New BatchedOpenLockContractTest pins the contract: - calling openBidiStreamLocked WITHOUT any lock throws - calling openBidiStreamLocked while holding lifecycleLock throws (the exact regression shape) - calling openBidiStreamLocked while holding streamsLock works (happy path) The runtime check is the regression-proof part: future callers physically cannot hold the wrong lock without the test (and prod) blowing up at the first call site. https://claude.ai/code/session_01HcvfQq1ttPV9PkRoJb4nyT	2026-05-07 03:18:18 +00:00