[SERVER-14304] Equality queries on _id with projection on _id may return orphan documents on sharded collections Created: 19/Jun/14  Updated: 11/Jul/16  Resolved: 19/Jun/14

Status: Closed
Project: Core Server
Component/s: Querying, Sharding
Affects Version/s: 2.6.0, 2.6.1, 2.6.2
Fix Version/s: 2.6.3, 2.7.3

Type: Bug Priority: Critical - P2
Reporter: J Rassi Assignee: J Rassi
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-14302 Equality queries on _id with projecti... Closed
related to SERVER-12902 Equality queries on _id aren't covered Closed
Tested
Operating System: ALL
Backport Completed:
Participants:

 Description   
Issue Status as of Jun 19, 2014

ISSUE SUMMARY
Queries on sharded collections that include an equality predicate on _id and specify a projection on {_id:1} (with no additional fields) may erroneously return orphan documents.

Example:

The following query has an equality predicate on _id and a projection on {_id:1} and is thus affected by the bug. It returns any orphaned documents present on any shards targeted by the query.

db.coll.find({_id:ObjectId("53a349440d3a24cdc742e1df"), baz:50}, {_id:1})

USER IMPACT
Queries on sharded collections that match the above conditions can return incorrect or duplicated results.

WORKAROUNDS
Add a hint of {_id:1} to these queries to avoid the issue.

AFFECTED VERSIONS
MongoDB production releases 2.6.0 - 2.6.2 are affected by this issue.

FIX VERSION
The fix is included in the 2.6.3 production release.

RESOLUTION DETAILS
The IDHackRunner has been changed to no longer allow covered projections on sharded connections.

Original description

If a sharded query that includes an equality predicate on _id and a projection of {_id: 1} targets shards with matching orphan documents, then the orphans will incorrectly be returned by the query.

The cause of this issue is a regression introduced in 2.6.0-rc2 (SERVER-12902). IDHackRunner incorrectly allows covered projections on sharded connections, and as such does not apply the sharding filter (which removes orphan documents).

Reproduce with the following:

var st = new ShardingTest({shards: 2});
var collName = "test.foo";
var collRouter = st.s0.getCollection(collName);
var collShard0 = st.shard0.getCollection(collName);
var collShard1 = st.shard1.getCollection(collName);
assert.commandWorked(collRouter.getDB().adminCommand({enableSharding: "test"}));
assert.commandWorked(collRouter.getDB().adminCommand({shardCollection: "test.foo",
                                                      key: {x: "hashed"}}));
assert.writeOK(collShard0.insert({_id: 1, x: 1}));
assert.writeOK(collShard1.insert({_id: 1, x: 1}));
assert.eq(2, collRouter.count());
assert.eq(1, collRouter.find().itcount());
assert.eq(1, collRouter.find({_id: 1}, {_id: 1}).itcount()); // Fails with "[1] != [2] are not equal".



 Comments   
Comment by Githook User [ 19/Jun/14 ]

Author:

{u'username': u'jrassi', u'name': u'Jason Rassi', u'email': u'rassi@10gen.com'}

Message: SERVER-14302 SERVER-14304 Fix IDHackRunner's use of sharding filter

(backport of 6fe6dee814326ac41f8d626c26bf32763ce73d71)
(cherry picked from commit 3d19c459fe80fb7aa3244174b61994f13f71c21f)
Branch: v2.6
https://github.com/mongodb/mongo/commit/ce54b89a5a015bb5c563f7f3cfb26f6af281cde2

Comment by Githook User [ 19/Jun/14 ]

Author:

{u'username': u'jrassi', u'name': u'Jason Rassi', u'email': u'rassi@10gen.com'}

Message: SERVER-14302 SERVER-14304 Fix IDHackRunner's use of sharding filter

(backport of 6fe6dee814326ac41f8d626c26bf32763ce73d71)
Branch: v2.6.3
https://github.com/mongodb/mongo/commit/3d19c459fe80fb7aa3244174b61994f13f71c21f

Comment by Githook User [ 19/Jun/14 ]

Author:

{u'username': u'jrassi', u'name': u'Jason Rassi', u'email': u'rassi@10gen.com'}

Message: SERVER-14302 SERVER-14304 Fix IDHackRunner's use of sharding filter
Branch: master
https://github.com/mongodb/mongo/commit/6fe6dee814326ac41f8d626c26bf32763ce73d71

Generated at Thu Feb 08 03:34:26 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.