# Upgrade event coverage (pre/during/post) > Source-anchored research for Upgrade event coverage (pre/during/post). Run status: COMPLETED. Parent: [MongoDB Upgrade Paths](https://llms-explorer.com/tree/mongodb-upgrade-paths/) · 3 facets · 13 facts · page: https://llms-explorer.com/tree/upgrade-event-coverage-pre-during-post/ ## How it works - Define coverage against the configured event scope. Confluent pipelines can filter namespaces or operation types; MongoDB documents that drop or rename closes affected collection or database cursors. Verify those boundaries when interpreting post-upgrade results. (medium confidence) — [source](https://docs.confluent.io/cloud/current/connectors/cc-mongo-db-source.html) ## Problems, failure modes and limitations - For a resumable error, the driver specification requires one automatic resume attempt with the original read preference; it does not require automatic recovery for every error. Successful resumed streams can later attempt another resume. Upgrade coverage must therefore include the application response when automatic recovery fails. (low confidence) — [source](https://github.com/mongodb/specifications/blob/master/source/change-streams/change-streams.md) - For quiet or highly filtered namespaces, checkpoint freshness matters even without business events. The driver specification exposes postBatchResumeToken positions from empty batches, and Confluent documents heartbeats that advance saved positions for low-volume namespaces. Heartbeats cannot prevent expiry while the connector is stopped. (high confidence) (verified as of 2026-10-23) — [source](https://github.com/mongodb/specifications/blob/master/source/change-streams/change-streams.md) - Resetting an expired checkpoint is a recovery policy, not evidence of complete historical coverage. Confluent latest startup skips existing source data and copy_existing copies current documents; Debezium snapshots current document state. Inference: a new snapshot cannot reconstruct every intermediate update or an already-deleted document from the missing interval. (medium confidence) (verified as of 2026-10-23) — [source](https://debezium.io/documentation/reference/stable/connectors/mongodb.html) - Before measuring coverage, define the watched scope and event filters. PyMongo documents separate collection, database and deployment watch scopes plus pipeline filtering; Debezium snapshots only collections matching its filters. Events excluded by configuration cannot be counted as covered simply because another watched collection resumes successfully. (medium confidence) — [source](https://www.mongodb.com/docs/languages/python/pymongo-driver/current/monitoring-and-logging/change-streams.md) ## Facts and statements - Before an upgrade, record the last processed consumer position and inspect the oplog time range. MongoDB recommends retaining operations longer than estimated upgrade downtime; Debezium resumes from its stored position only while the necessary history remains available. Allowing additional catch-up time is an operational inference from these requirements. (high confidence) — [source](https://www.mongodb.com/docs/manual/administration/change-streams-production-recommendations/) - During maintenance of a primary-secondary-arbiter replica set, taking the secondary offline can prevent majority commits. The change stream may remain open while delivering no notifications; catch-up depends on retaining the relevant oplog history. A connected consumer therefore does not by itself prove event coverage. (low confidence) — [source](https://www.mongodb.com/docs/manual/administration/change-streams-production-recommendations/) - After upgrade interruptions or worker crashes, plan for replay and idempotent downstream handling. Debezium documents duplicates after restart from the last flushed offset, and Confluent explicitly documents at-least-once delivery and duplicate records after failures or restarts. (high confidence) (verified as of 2026-10-23) — [source](https://debezium.io/documentation/reference/stable/connectors/mongodb.html) - A practical post-upgrade acceptance check should compare known writes and downstream results across the maintenance interval, alongside connector lag, event counts and checkpoint progress. This is a synthesized verification method: Debezium exposes event counts, connection status, source position and lag, while MongoDB documents connected-but-idle streams during upgrades. Those metrics alone do not prove absence of gaps. (medium confidence) (verified as of 2026-10-23) — [source](https://debezium.io/documentation/reference/stable/connectors/mongodb.html) - Persisting only the last matching business-event token can leave a quiet consumer with an old checkpoint. A Mongoose discussion reports this problem and contrasts wrapper behavior with the underlying driver resume-token-change event; the driver specification explains why post-batch tokens can be newer than the last matching event. The discussion is historical evidence, not proof of a current Mongoose defect. (medium confidence) — [source](https://github.com/Automattic/mongoose/discussions/13602) - After resuming a filtered change stream from an older token, delayed first delivery need not mean permanent event loss: Alex Bevilacqua's reproducible MongoDB 5.2.0 three-node test shows resumption delay with intervening oplog events, and the MongoDB driver specification warns that an old resume token can require scanning more oplog entries. The measured timings belong to that test setup and should not be generalized to current deployments. (medium confidence) — [source](https://alexbevi.com/blog/2022/03/02/performance-analysis-of-resuming-a-mongodb-change-stream/) - If coverage requires the document before or immediately after each change, request the appropriate image semantics. PyMongo distinguishes stored pre/post-images from updateLookup, which may return a later document version. Therefore post-upgrade full-document lookup is not by itself evidence of the exact document state at every intervening update. (low confidence) — [source](https://www.mongodb.com/docs/languages/python/pymongo-driver/current/monitoring-and-logging/change-streams.md) - Suggested coverage test, inferred from the delivery semantics: issue identifiable changes before, during and after maintenance, then reconcile expected events at the destination. Allow catch-up and distinguish duplicates from missing changes. (medium confidence) — [source](https://debezium.io/documentation/reference/stable/connectors/mongodb.html)