Skippr Docs

Appearance

How MongoDB CDC Resume Behavior Works ​

May 2026

MongoDB CDC resume behavior is built on resume tokens. Skippr stores the token after each committed batch and uses resume_after when the stream starts again.

Short Answer ​

MongoDB CDC resume behavior in Skippr uses the MongoDB resume token. After each committed change batch, Skippr stores the token. On restart, it reopens the change stream with resume_after so the stream continues from that stored position.

That is the right way to think about restart safety in MongoDB CDC. The pipeline does not merely remember that it had been running. It remembers the committed change-stream token that MongoDB itself uses to identify where to continue.

Why Teams Struggle with This ​

Resume gets fuzzy when teams talk about restarts at the process level instead of at the change-stream position level. The docs make it specific: the durable resume point is the resume token stored after a committed batch.

  • The source must support change streams, which means a replica set or sharded cluster.
  • The resume position is the MongoDB resume token, not an inferred timestamp.
  • Restart uses resume_after with that stored token.
  • The general CDC guarantee still stops if source retention expires before the runner resumes.

How Skippr Handles It ​

Skippr keeps the MongoDB recovery story grounded in native source behavior. The same source feature that makes continuous capture possible, the change stream, also provides the native token used for restart.

That makes the CDC contract easier to explain. A committed warehouse apply can be tied back to a committed source position that MongoDB itself understands, rather than to a custom approximation.

  • Resume tokens are stored after each committed change batch.
  • Restarts reopen the change stream with resume_after.
  • The restart cursor is a native MongoDB token, not an app-specific offset.
  • Resume behavior stays aligned with committed source ownership of events.

What the First Useful Version Looks Like ​

MongoDB restart behavior is easiest to trust when you focus on the token, not the process. The process can die and return. The useful question is whether the token was stored after the last committed batch.

That is the detail that makes the resume story concrete.