[lamchun1110]

What

Fixes #10315.

buildStreamingResponseHeaders in open-sse/handlers/chatCore/responseHeaders.ts emitted a full warn (with up to 20 dropped header entries) on every SSE response whose upstream headers exceeded the 768-byte forwarding budget. The dropped set is usually identical across responses from the same upstream, so under Desktop multi-stream use this produced dozens of identical warns per minute — burying real errors and adding event-loop serialization work.

Change

• Fingerprint each drop set (sorted, lowercased dropped-header names) in a module-level Set (capped at 1000 fingerprints, cleared on overflow rather than growing unbounded).
• Warn once per unique fingerprint per process; subsequent identical drops log at debug level.
• Extend ResponseHeaderLogger with an optional debug method (the injected defaultLogger already has one).
• Export fingerprintDroppedHeaders and a resetDroppedHeaderWarnFingerprints test hook.

Tests

Added tests/unit/chatcore-header-drop-warn-dedupe-10315.test.ts:

1. 100 identical oversized responses → exactly 1 warn + 99 debug (the validation plan's criterion: 100 identical oversized calls yield at most one warn)
2. A different drop set warns again
3. Fingerprint is order-insensitive to dropped header names
4. Reset hook forgets fingerprints so the same set warns again
5. Responses within budget never warn

Verified locally: new file passes (5/5); related existing suites pass (chatcore-streaming-response-headers, forwarded-header-budget, chatcore-nonstreaming-response-headers, upstream-response-headers-strip, mcp-sse-response-headers-8277, middleware-header-strip-5849 — 37/37; g13-combo-chatcore-golden, chatcore-translation-paths — 73/73); npm run lint clean.

Changelog fragment

Added under changelog.d/fixes/ with this PR's number.

[diegosouzapw]

Thanks for the clean fix — this maps directly onto the validation plan from #10315.

I checked out the branch and ran the new test file plus the six related existing suites you named (chatcore-streaming-response-headers, forwarded-header-budget, chatcore-nonstreaming-response-headers, upstream-response-headers-strip, mcp-sse-response-headers-8277, middleware-header-strip-5849): 5/5 new tests pass, 32/32 related tests pass, and eslint on the touched files is clean. I also confirmed the only production call site of buildStreamingResponseHeaders (in streamingResponseHeaders.ts) always uses the default logger, which already implements .debug, so this is fully backward compatible with the existing call chain.

No changes requested — this looks merge-ready as-is. Two very minor optional notes for the future, neither blocking:

• The fingerprint set is capped at 1000 entries and clears wholesale on overflow rather than using an LRU/TTL — fine for the reported storm, just something to revisit if the process ever sees a huge number of distinct upstream header shapes over a long uptime.
• The fingerprint is name-set only (ignores byte sizes), so two drop sets with the same dropped names but different sizes collapse into a single warn — this matches your issue's own suggested design, just flagging for awareness.

Nice work isolating this from the header-budget/priority logic itself, keeping the diff focused on the logging path only.

[diegosouzapw]

Validated in local merge-train .claude/worktrees/merge-train-20260816-000002-suite.log on devbox-vm-06-dev002 @ 8be62df65f61cc4cf29cdc3e6bc38173ffafa4e3 (FAST gates green: static + changed tests + vitest; daily full-suite run still required). Merged under the batch merge-train protocol (merge-gates §7). ⚠️ base-red inherited: #10523 (ServiceSupervisor order-dependent test, not touched by this batch).