Question

You built a change feed consumer using the .NET SDK's change feed processor to project order events into a downstream reporting container. To maximize throughput, you configured the processor to checkpoint only after every 500 processed changes rather than after each batch. During a load test, the host process crashed unexpectedly. When the processor restarts, what behavior should you expect, and what is the primary trade-off of your checkpoint configuration?

Accepted Answer

The processor resumes from the last checkpoint, so up to 500 already-processed changes may be delivered again, requiring your delegate to handle duplicates idempotently.

Answer

The processor resumes exactly where it stopped with no reprocessing, because the SDK persists an in-memory offset independent of the lease container.

Answer

The processor skips all changes that occurred while the host was down, causing permanent data loss in the reporting container.

Answer

The processor automatically re-reads the entire change feed from the beginning because a crash invalidates all lease documents.