A copper-roof workshop runs a long-lived worker that must checkpoint Cosmos change-feed progress so a restart does not replay the entire history. Which approach should the developer use?
Select an answer to reveal the explanation.
Short Explanation
Treat leases like bookmarks in a shared library book. The change feed processor plus a lease container remembers where you stopped so restarts do not reread the whole catalog. That is at-least-once checkpointing—not a Functions-only rule.
Full Explanation
A copper-roof workshop with a long-lived worker that must checkpoint Cosmos change-feed progress should use the change feed processor with a lease container. The processor coordinates workers and persists continuation state in leases so a restart resumes near the last checkpoint instead of replaying the entire history. That lease-based bookmarking is the standard at-least-once checkpoint model for continuous processors hosted in App Service, Container Apps, VMs, or similar.
Claiming only a Cosmos-triggered Azure Function can checkpoint is false: Functions are one hosting path that uses the same change-feed ideas, but processors outside Functions also checkpoint via leases. Storing progress in a local text file without a lease container fails when the worker moves hosts, scales out, or crashes before flush, and it does not participate in feed-range distribution. Disabling the change feed and polling with SELECT * after every restart abandons incremental processing and reintroduces full-scan cost and race conditions.
Exam caveat: checkpoints imply at-least-once delivery—design handlers to be idempotent because a crash between processing and lease advance can redeliver an item.
Operational check: configure a dedicated lease container, stop the worker mid-feed, restart it, and verify it continues from the persisted lease offsets rather than from the container’s beginning.