New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Oplog inconsistent after using dropDatbase #3847

hitchcott opened this Issue Mar 2, 2015 · 5 comments


None yet
2 participants

hitchcott commented Mar 2, 2015

Fringe scenario I've run into. I'm experimenting with mongo's db.dropDatabase inside a Meteor package. I would expect the app deal with this operation; the data is gone, and I assume poll-and-diff would pick that up.

Moreover, if I try to re-insert old documents after the dropDatbase, I get the following error:

Error in oplog callback Error: insert found for already-existing ID in published
    at packages/mongo/oplog_observe_driver.js:562:1
    at Object.Meteor._noYieldsAllowed (packages/meteor/fiber_helpers.js:11:1)
    at [object Object]._.extend._handleOplogEntrySteadyOrFetching (packages/mongo/oplog_observe_driver.js:545:1)
    at packages/mongo/oplog_observe_driver.js:118:1
    at packages/mongo/oplog_observe_driver.js:16:1
    at Object.Meteor._noYieldsAllowed (packages/meteor/fiber_helpers.js:11:1)
    at packages/mongo/oplog_observe_driver.js:106:1
    at packages/mongo/oplog_tailing.js:79:1
    at runWithEnvironment (packages/meteor/dynamics_nodejs.js:108:1)
    at packages/meteor/dynamics_nodejs.js:121:1

I assume this is because Meteor thinks that the documents were never removed.

There are a couple of solution I can think of, which I'm pursuing right now:

  1. Force a resync of db in the Meteor app after dropDatabase
  2. Account for dropDatbase in the OplogObserveDriver
  3. Drop each collection individaully

Any pointers would be appreciated.


This comment has been minimized.

hitchcott commented Mar 2, 2015

It looks like dropping each collection rather than the database is a workaround for my use case. It's also also a better approach in general.

I'm not going to try to solve this issue, but I guess I'll leave it open in case anyone thinks it's a genuine bug.


This comment has been minimized.


glasser commented Mar 3, 2015

Good call. We currently do specially look for "drop collection" messages in the oplog, but not for "drop database" messages.

It would be great if you could follow our guidelines for reporting bugs and include an easy-to-test reproduction:

(Note that the answer in your link doesn't seem to have anything to do with "drop collection" vs "drop database" but just with "drop database" vs "remove all" --- ie, the fact that when you drop something the indices go away.)


This comment has been minimized.

hitchcott commented Mar 3, 2015

Yup, my bad about the remove and drop distinction.

Reproduction on the way.


This comment has been minimized.

hitchcott commented Mar 5, 2015

I've put together a reproduction here:

At first I tried something like this on the server:

testCol.insert { '_id' : 'test' }
console.log "docs before: #{testCol.find().count()}"
console.log "docs after: #{testCol.find().count()}"

But that worked as expected. So it seems the problem is limited to updating clients rather than the entire app being unaware of the dropDatabase.

@glasser glasser closed this in 44d387c Apr 1, 2015


This comment has been minimized.


glasser commented Apr 1, 2015

Thanks for the reproduction. Fixed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment