Problem
clients/web/src/test/core/mcp/fetchTracking.test.ts (~line 391) proves secret redaction by asserting the serialized tracked entry does not contain a secret value, e.g. expect(JSON.stringify(tracked[0])).not.toContain("shh").
Redaction works correctly (client_secret=[REDACTED] in the body), but the tracked entry also carries a randomly-generated request id like 1784862417663-sw7kshhf0. Short secret values can appear by coincidence as a substring of that base36 id — sw7kshhf0 contains shh — producing a spurious failure. The test passes on re-run.
Observed once during npm run ci on PR #1756 (unrelated cast-cleanup work).
Fix options
- Seed the request id deterministically in the test (inject a fixed id), or
- Assert on the specific redacted fields / the redacted-token span rather than a bare
toContain substring over the whole serialized object, or
- Use secret fixtures that can't collide with the
[0-9a-z] id charset.
Impact
Low — cosmetic CI flake, no product bug. But it can fail an otherwise-green npm run ci / CI run, so worth making deterministic.
Problem
clients/web/src/test/core/mcp/fetchTracking.test.ts(~line 391) proves secret redaction by asserting the serialized tracked entry does not contain a secret value, e.g.expect(JSON.stringify(tracked[0])).not.toContain("shh").Redaction works correctly (
client_secret=[REDACTED]in the body), but the tracked entry also carries a randomly-generated request id like1784862417663-sw7kshhf0. Short secret values can appear by coincidence as a substring of that base36 id —sw7kshhf0containsshh— producing a spurious failure. The test passes on re-run.Observed once during
npm run cion PR #1756 (unrelated cast-cleanup work).Fix options
toContainsubstring over the whole serialized object, or[0-9a-z]id charset.Impact
Low — cosmetic CI flake, no product bug. But it can fail an otherwise-green
npm run ci/ CI run, so worth making deterministic.