Checkpoint and Replay

A checkpoint preserves a recoverable point in a computation. For a stateful stream this includes coordinated operator state and source progress; the exact contents depend on the engine and checkpoint mode. Replay reads retained input again from that point to reconstruct later state. A position without the corresponding aggregate is not enough.

If a checkpoint records state after records 0 through 999 and the next position is 1000, a crash before record 1234 means replay starts at 1000. The 234 already processed records are recomputed from the restored state, not added to the lost state a second time. This requires the input still to exist and compatible code and reference data. External lookups or clocks can make replay nondeterministic.

An email sent before failure is not undone by restoring a checkpoint. End-to-end exactly-once effects require a compatible sink protocol or replay-safe operations within a stated boundary. Nor does recovery recover events intentionally dropped by the lateness policy: it reproduces that policy. Test restoration, input retention, sink behavior and state compatibility, rather than treating a successful checkpoint write as proof of recovery.

Reference: Flink checkpoints.