Database Testing / Scenario
The Test That Sees Ghosts
An integration test fails one run in six: the row is THERE, but the test cannot see it. The suspect is not timing. It is a transaction snapshot.
- Difficulty
- Hard
- Format
- Scenario
- Points
- 200
- Estimate
- 15 min
// MISSION BRIEF
Your Mission
test_order_appears_in_history is the team's most re-run test. The
"fix" PRs so far: sleep(2), sleep(5), and retry(3), all merged, none worked.
Read the test, the app behavior, and the isolation notes, then diagnose it
like a database person instead of exorcising it like a ghost.
Scoring: weighted decisions; the root-cause call counts double.
// FIRST CONTACT
Battle teaser
First artifact
test_order_history.py (excerpt)
The root cause of the intermittent failure:
- Apytest fixtures execute in random order
- BMySQL loses inserts under load about 17% of the time
- CThe test reads inside a long-open REPEATABLE READ transaction whose snapshot began at the warm-up query; the app's later commit is invisible to that snapshot, and pool reuse shifts when the snapshot starts, hence intermittence
- DThe API sometimes fails to commit; its logs must be wrong
Answers, scoring, hints, and the full battle stay sealed.
// SKILL TAGS
database-testingtransactionsisolation-levelsflaky-tests