🤖 tests: backup payload MCP-redaction test counts unrelated global JSON.stringify calls
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 85/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- bun, typescript
- Domain
- testing-qa
Research direction
Start in src/node/services/backup/payload.test.ts at the "rejects too many MCP redactions before serializing paths" test, then run that targeted test under Bun. Check how the JSON.stringify spy records calls across the await, and make the assertion depend only on backup-payload serialization. Done means the test passes reliably without unrelated global calls affecting its count.
Written by the indexing model from the issue text.
Description
Flake
src/node/services/backup/payload.test.ts > "backup payload > rejects too many MCP redactions before serializing paths" failed in the merge queue (run https://github.com/coder/xum/actions/runs/36353983065, job Test / Unit (6/6), for #4915, which does not touch backup code):
986 | expect(stringify.mock.calls).toHaveLength(0);
error: expect(received).toHaveLength(expected)
Expected length: 0
Received length: 3
Likely cause
The test spies on the global JSON.stringify and asserts zero calls across an await. Any async work still running in the same Bun process (for example a late config, lease or status write from an earlier test file in the shard) that calls JSON.stringify meanwhile is counted.
Possible fix
Assert on calls whose arguments come from the backup payload (filter the spy's calls), or inject the serializer instead of spying on the global.
Log
- 2026-09-27: #4915 removed from the merge queue by this failure; re-enqueued (1/3).
Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $8.57
- Dominant language
- TypeScript
- Stars
- 2k
- Forks
- 136
- Avg merge
- 8h 34m
- Merged PRs (30d)
- 620
Getting set up
We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from coder/xum
-
backlog refactor
Difficulty 2/5 Half a day Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
backlog
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 38/100
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Maintainers usually reply within 1 day
Similar issues
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 88/100
StabilityNexus/Fate-EVM-Frontend#153 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
code-yeongyu/oh-my-openagent#9039 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Tencent/teamai-cli#862 ·
Maintainers usually reply within 1 day
-
bug good first issue hacktoberfest redis
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
libredb/libredb-studio#1164 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
oracle/langchain-oracle#323 ·
Maintainers usually reply within 1 day