This is the definitive answer for this thread — and a sharper diagnosis than mine. I'd flagged the readStream intermediate as where the checkpoint risk lives, but your point is stronger: it doesn't just risk breaking, it makes deletion detection structurally impossible, since an append-only intermediate never loses a key. That's a subtle failure mode because everything *looks* healthy while silently never closing a record.

The partial-load scenario in your point 2 is the one I'd underline for anyone finding this later: a snapshot read against a half-loaded source end-dates every key it can't see, with no signal. Orchestrating both as tasks in one job + a row-count expectation on the view is cheap insurance against an expensive, quiet data corruption.

One small clarification if you have a moment: is passing the source table name directly as a string to create_auto_cdc_from_snapshot_flow also supported, or is the @DP.view wrapper the required/recommended shape? Asking because the string form shows up in older examples and it'd be good to know if it behaves identically.