[SERVER-32629] $lookup misses results when both the mongos and primary shard are unaware that an involved collection is sharded Created: 10/Jan/18  Updated: 27/Oct/23  Resolved: 22/Apr/20

Status: Closed
Project: Core Server
Component/s: Aggregation Framework
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Nicholas Zolnierz Assignee: Backlog - Query Team (Inactive)
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-47556 AutoGetCollectionForReadCommand: Conv... Closed
Assigned Teams:
Query
Participants:

 Description   

Found while working on test cases for SERVER-32308. Repro steps:

1. Create unsharded local and foreign collections, inserting a few documents to each.
2. Shard either collection through the first mongos, and ensure that the chunks are distributed across multiple shards.
3. Restart the primary shard to reset its metadata. It now believes that both collections are unsharded.
4. Send $lookup to a second mongos, which is unaware that either collection is sharded.



 Comments   
Comment by Kaloian Manassiev [ 22/Apr/20 ]

This issue is now gone away as a result of the changes done under SERVER-47556 and the respective test lookup_mongod_unaware.js has been updated.

Comment by Kaloian Manassiev [ 10/Jan/18 ]

I think it should stay open so that the respective tests can be written, once the dependent bug is fixed.

Comment by Andy Schwerin [ 10/Jan/18 ]

So, close as duplicate?

Comment by Kaloian Manassiev [ 10/Jan/18 ]

This scenario is not limited to $lookup only. I believe any query will encounter the same problem. SERVER-32198 will take care of this, yes.

Comment by Esha Maharishi (Inactive) [ 10/Jan/18 ]

kaloian.manassiev, will this be solved once shards have an "unknown" metadata state?

Generated at Thu Feb 08 04:30:48 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.