QABattle

Database Testing / Scenario

The 588 Missing Rows

Source says one million rows. Target says one million and change. The reject file says 122. Nothing adds up, until you find the two bugs canceling each other out.

Difficulty
Hard
Format
Scenario
Points
200
Estimate
15 min

// MISSION BRIEF

Your Mission

Last night's customer-orders load "succeeded". The reconciliation dashboard disagrees with itself: the target has MORE rows than expected in some batches and fewer in others. You have the run log, a duplicate probe, and the filter definitions. Untangle the arithmetic.

Scoring: weighted decisions; the count-forensics call counts double.

// FIRST CONTACT

Battle teaser

First artifact

Pipeline run log (nightly load, 2026-07-08)

Why did a plain source-vs-target row count fail to flag this load cleanly?

  1. AThe dashboard queried the wrong cluster
  2. BTwo independent errors partially cancel: 122 rejected + missing rows shrink the target while 466 retry duplicates inflate it; a net count is a sum of errors, only key-level (set difference) reconciliation separates them
  3. COne million rows is too many to count reliably
  4. DRow counts are meaningless in ETL validation and should be dropped
Answers, scoring, hints, and the full battle stay sealed.

// SKILL TAGS

etldatabase-testingreconciliationidempotency