Production engineering
Reveal answer and reasoning
Design retries around a complete owned unit with explicit inputs, fresh reads, an atomic local write and no unaccounted external effect. Record a maximum attempt or time budget and classify provider errors deliberately. Preserve the independent snapshot and final-state observations, since a successful final command alone cannot prove the decision used fresh state. The companion arithmetic helps explain why twenty-one is intended; actual SQLite execution supplies the isolation and failure evidence.
A different engine or transaction mode needs its own integration checks instead of inheriting these conclusions merely because it exposes a transaction API.
For production work, decide whether retrying the entire unit is semantically allowed before selecting a library policy. Keep any remote delivery outside the local transaction or use an explicit outbox and consumer protocol for its separate failure window. Avoid holding a database transaction open while awaiting unrelated network work. Capture enough structured context to classify the failure without logging secrets or every SQL value.
Tests should force the stale-read boundary and inspect fresh persisted state, rather than pass because any second command eventually returned without throwing.
What a strong answer covers
- The portable program prints snapshot10, fresh20 and replayed21.
- The actual WAL reader and fresh connection observe different committed snapshots.
- A safe retry starts a fresh unit and repeats its dependent reads; it does not imply remote rollback.
Common pitfall
Retrying only the failed UPDATE while retaining a stale decision or repeating an external effect.
Follow-up questions
- Which transaction modes or providers would require different isolation evidence?
- What changes if the unit also sends a remote message before committing?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.