Skip to content
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

Client inserted document _id is incorrect in under some circumstances #2097

vsivsi opened this issue Apr 30, 2014 · 3 comments


Copy link

vsivsi commented Apr 30, 2014

I'm seeing a new bug in v0.8.1.0 where if the client inserts a new document:

id = new Meteor.Collection.ObjectID();
ret_id = collection.insert({ _id: id }, function(err, cb_id) {
    // id == ret_id == cb_id here
    doc = collection.findOne({ _id: cb_id });
    // doc is undefined here, because document on server got a different _id

The document that ends up in the database has a different _id from the ids returned by the insert on the client (both ret_id and cb_id in the snippet above).

The bug seems to require both that the client provide an _id in the document it's inserting, and that an insert "allow rule" is called on the server side.

It doesn't seem to matter if the "insecure" package is installed or not. The document _id in the allow function is correct (it matches the values seen on the client), but sometime after that, the document gets inserted on the server with a new _id and then that change propagates back to the client.

I'm working on a simplified repro case right now. Done: see comment below.

Copy link

vsivsi commented Apr 30, 2014

This meteor project reproduces this bug.

@vsivsi vsivsi changed the title Client inserted document's _id is incorrect in under some circumstances Client inserted document _id is incorrect in under some circumstances Apr 30, 2014
vsivsi added a commit to vsivsi/meteor that referenced this issue May 1, 2014
…ent supplied _id with undefined for validated inserts, which led mongodb to create a new _id for each such document.
Copy link

vsivsi commented May 1, 2014

See pull request for fix: #2099

Copy link

glasser commented May 1, 2014

Thank you for a good report, reproduction, and PR (though I used a different fix instead). I am embarrassed that this code was untested; I added a test. We will probably put this in a shortly.

glasser added a commit that referenced this issue May 1, 2014
This was a regression in 0.8.1 which caused client-specified `_id` to
always be ignored for collections with at least one allow/deny rule.

Fixes #2097. Fixes #2099.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

2 participants