Flaky Test Triage

Diagnose intermittent test failures by cause class, get the experiment that confirms each, and fix the root rather than adding retries.

Help me fix this flaky test.

The test and any helpers it uses:
"""
[PASTE THE TEST, ITS SETUP AND TEARDOWN, AND THE CODE UNDER TEST]
"""

Failure output from a failing run:
"""
[PASTE THE ERROR AND STACK TRACE]
"""

Failure rate: [e.g. "1 in 20 runs", "only in CI", "only when the full suite runs"]
When it started: [AFTER WHAT CHANGE, or "unknown"]
Environment differences between local and CI: [PARALLELISM, CPU COUNT, TIMEZONE, DATABASE, CONTAINERS]
Does it fail alone: [YES/NO, and what changes when run in isolation]

Work through this:

1. **Classify the cause.** Rank the plausible cause classes for this specific test with the evidence for each:
- Time: real clocks, timezones, dates near a boundary, timeouts tuned to a fast machine
- Order and shared state: leaked global state, database rows or files left behind, module-level caches
- Concurrency: real async races, missing awaits, fixed sleeps standing in for waits
- Resources: ports, temp files, memory or CPU contention under parallel runs
- Randomness: unseeded generators, unstable iteration or serialization order
- External: network calls, real clocks in dependencies, unpinned test data
The isolation behavior above is the strongest single clue, so weight it heavily.

2. **The discriminating experiment.** For the top hypothesis, the cheapest way to confirm it: a seed, a forced order, a clock freeze, a parallelism change, a loop that runs the test 200 times. Give me the exact command or snippet, and say what result confirms versus kills the hypothesis.

3. **The real fix.** Fix the cause, not the symptom. Rank fixes: remove the nondeterminism, then control it (inject the clock, seed the generator, wait on a condition rather than a duration), then last and only with justification, isolate the test. Never propose a retry wrapper or an increased timeout as the fix; say explicitly if that is all that is available and what it costs.

4. **Is the test or the code wrong?** Some flakes are the test correctly detecting a real race in the code. Say which this is, since one of those is a bug worth more than the test.

5. **Prevention.** What would catch this class of flake before it reaches main: a suite-wide setting, a lint rule, a randomized-order run in CI.

If the pasted material is not enough to tell these classes apart, say what to capture on the next failure instead of guessing.

How to use

The isolation question does most of the diagnostic work: a test that only fails in the full suite is a shared-state or ordering problem, and one that fails alone is usually timing or randomness. Step 4 is the one worth slowing down for, because a meaningful share of flaky tests are correctly reporting a real race that will eventually happen in production, and the retry wrapper that silences it is the most expensive one-line change on the team.

More coding prompts

Write the commit message for this change.

Diff:
"""
[PASTE THE STAGED DIFF]
"""

Why I made this change: [THE REASON, THE TICKET, THE BUG REPORT, or "you infer it"]
Convention: [Conventional Commits / this repo's existing style, pasted below / plain]
Recent commits from this repo, to match style:
"""
[PASTE 5-10 RECENT COMMIT SUBJECT LIN

Commit Message

Write a commit message that explains why the change was made, in Conventional Commits format, split into separate commits when needed.

Codingbeginner

Help me recover from a git mistake without making it worse.

What I was trying to do: [THE GOAL]
What I ran: [THE EXACT COMMANDS, IN ORDER]
What happened instead: [THE OUTPUT OR THE STATE NOW]
Has this been pushed or shared: [YES/NO, and to which branch and whether anyone else has pulled]
Uncommitted work I cannot lose: [WHAT AND WHERE, o

Undo a Git Mistake

Recover from a bad commit, force push, wrong branch, or lost work with a reversible plan and the exact commands, explained before you run them.

Codingintermediate

Handler code, routes, and models:
"""
[PASTE THE ROUTE DEFINITIONS, HANDLERS, REQUEST AND RESPONSE TYPES, VALIDATION SCHEMAS, AND MIDDLEWARE]
"""

Generate an OpenAPI 3.1 specification from the code above.

API name, version, and base URL: [DETAILS]
Auth scheme: [BEARER JWT / API KEY / OAUTH / SESSION COOKIE, and where it is enforced]
Con

OpenAPI Spec From Code

Generate an accurate OpenAPI 3.1 spec from handler code, including error responses and auth, with gaps flagged instead of invented.