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

Closed
vsivsi opened this Issue Apr 30, 2014 · 3 comments

Projects

None yet

2 participants

@vsivsi
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.

@vsivsi
vsivsi commented Apr 30, 2014

This meteor project reproduces this bug. https://github.com/vsivsi/meteor-client-id-bug

@vsivsi vsivsi changed the title from Client inserted document's _id is incorrect in 0.8.1.0 under some circumstances to Client inserted document _id is incorrect in 0.8.1.0 under some circumstances Apr 30, 2014
@vsivsi vsivsi added a commit to vsivsi/meteor that referenced this issue May 1, 2014
@vsivsi vsivsi Fixes #2097 - null !== undefined lead to always overwriting client su…
…pplied _id with undefined for validated inserts, which led mongodb to create a new _id for each such document.
2c1caa6
@vsivsi
vsivsi commented May 1, 2014

See pull request for fix: #2099

@glasser glasser added a commit that closed this issue May 1, 2014
@glasser glasser Follow-up to 4777e64: fix client-specified _id
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.
5e0845a
@glasser glasser closed this in 5e0845a May 1, 2014
@glasser
Member
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 0.8.1.1 shortly.

@glasser glasser added a commit that referenced this issue May 1, 2014
@glasser glasser Follow-up to 4777e64: fix client-specified _id
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.
1d40046
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment