A batch load fails halfway through writing to a table managed by an open table format. What do readers see?
Select an answer to reveal the explanation.
Short Explanation
Nothing committed, so nothing changed. You keep reading the last good snapshot and never learn the load failed, which is the behavior you want at three in the morning.
Full Explanation
The correct answer is the previous complete state of the table, because the failed write never committed. Atomicity means a write becomes visible only on a successful commit. A failure partway through leaves the metadata pointing at the previous snapshot, so readers continue to see the last complete state. The partially written rows, until an administrator cleans them up, is incorrect because uncommitted files are not part of the table; they are not visible to readers even though they may exist in storage pending cleanup. The error because the table is left in an inconsistent state is incorrect because avoiding an inconsistent readable state is precisely what the commit protocol delivers. The empty table because the failure resets the current snapshot is incorrect because a failed write does not discard the existing table. For the exam, the answer to any partial-write scenario under a table format is that readers see the last committed state.