# Flaky-test investigation

## Decision flow
1. Preserve failing evidence: build, environment, worker, seed, trace, logs and test data.
2. Can the failure repeat in isolation with the same starting state?
   - Yes: compare expected behaviour with actual responses; investigate the product or the test expectation.
   - No: run alongside the neighbouring tests with the same data arrangement.
3. Does the failure depend on order or parallel execution?
   - Yes: inspect shared accounts, mutable fixtures, cleanup and resource limits.
   - No: inspect explicit waits, asynchronous completion and external dependencies.
4. Does the application violate the agreed requirement in the captured evidence?
   - Yes: open a product defect with a reproducible state.
   - Unknown: obtain the missing observation or clarify the requirement.
   - No: repair the test or environment and demonstrate the corrected condition.
5. Repeat under the conditions that previously failed. Document the result and remaining uncertainty before restoring the gate.

## Investigation log
| Run / build | Isolation or suite | Workers / seed | Data state | Result | Evidence |
| --- | --- | --- | --- | --- | --- |
| Original failure | | | | | |

## Hypothesis register
| Hypothesis | Observation supporting it | Experiment | Outcome | Next action |
| --- | --- | --- | --- | --- |
| Shared account mutation | | | | |
| Missing completion condition | | | | |
| External provider variability | | | | |

## Quarantine record
- Affected check and release risk:
- Alternative evidence until repair:
- Owner / expiry / issue:
- Conditions required for restoration:

Example — fictional: a test passes alone but fails when another worker deletes its shared account. The repair creates an account per test and cleans up only that account. Verify the previously conflicting tests together; increasing a timeout would not address the observed data collision.