The comment added in #11649 said keeping the API key id out of the digest
"avoids the false-positive CodeQL js/insufficient-password-hash on a cache/dedup
key". It does not. CodeQL raised alert #874 on the `createHash` in this very
function on the first scan after that merge: once an API-key-derived value
reaches the file at all, the query flags the sibling digest regardless of what
goes into it.
The plaintext prefix is still the right call — a namespace you can read off the
key beats one you cannot when debugging a dedup collision, and it matches
`semanticCache.generateSignature` (#3740), whose comment makes the same
incorrect claim. But a rationale that is measurably false is worse than no
rationale: the next person edits here, sees the alert the comment promised would
not happen, and doubts the design instead of the comment.
Replaced with what actually holds, plus the two things worth knowing: the alert
is dismissed per HR#14 and will come back on any edit here, and it must not be
"fixed" with a KDF — that would break the determinism dedup depends on.
Comment-only. No behaviour change; request-dedup tests 15/15.
Merged via /merge-batch (2026-08-26, v3.8.51). Boarded no worktree combinado; validação única: typecheck/complexity/cognitive-complexity/file-size/changelog verdes, lint nos mesmos 228 achados pré-existentes confirmados contra o tip puro, testes focados passando. Obrigado pela contribuição.
* fix(open-sse): stop concurrent requests colliding on dedup hash for non-OpenAI formats
computeRequestHash() in requestDedup.ts projected the prompt content from
body.messages only. The dedup site in chatCore.ts hashes the *translated*
(target-format) request body, and non-OpenAI target formats don't carry a
messages field: Gemini-translated bodies use `contents`, Responses-API
bodies use `input`. So for those formats messages was always undefined,
every prompt hashed to the same null-backed value for a given model, and
concurrent requests with different prompts joined the same in-flight
promise -- the second caller silently received the first caller's
response verbatim (#10249).
Fix: project body.messages ?? body.contents ?? body.input ?? null instead
of only body.messages, keeping the rest of the canonical hash projection
unchanged. Genuinely identical concurrent requests still dedupe (the
intended perf behavior); different prompts under Gemini/Responses-API
target formats no longer collide.
Regression test: tests/unit/request-dedup-10249.test.ts reproduces the
two collision scenarios from the plan-file (Gemini `contents`,
Responses-API `input`), confirms the OpenAI `messages` case was already
correct, and asserts identical-request dedup keeps working. Verified
RED (byte-identical hashes 0b24fd88.../dc16d5b7... pre-fix) -> GREEN
(distinct hashes, dedup preserved) against this exact diff.
* fix(open-sse): cover nested translator shapes + system fields in dedup hash (#10438)
computeRequestHash() only read top-level body.messages ?? body.contents ??
body.input, but several translated request shapes nest their prompt
content: the Antigravity Cloud Code envelope under request.contents, and
Kiro under conversationState.currentMessage.userInputMessage.content (plus
conversationState.history). Two different concurrent prompts to those
targets could hash identically and share/leak a response between callers.
Adds extractPromptContent()/extractSystemContent() helpers covering every
prompt-bearing shape produced by open-sse/translator/request/*.ts
(OpenAI/Cursor messages, Claude messages+system, Gemini contents+
systemInstruction, Responses input+instructions, Antigravity and Kiro
nesting), and folds system/instructions/systemInstruction into the
canonical hash so two requests with the same user message but a different
system prompt no longer collide either.
---------
Co-authored-by: adevwithpurpose <adevwithpurpose@users.noreply.github.com>
