[SERVER-13364] geoNear command doesn't handle versioning correctly Created: 26/Mar/14  Updated: 06/Dec/22  Resolved: 08/Mar/18

Status: Closed
Project: Core Server
Component/s: Geo, Sharding
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Siyuan Zhou Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-27664 Remove all usages of ShardConnection ... Closed
Related
is related to SERVER-13365 Disable balancer for geoNear sharding... Closed
is related to SERVER-21497 Disable yield_geo_near_dedup.js FSM w... Closed
Assigned Teams:
Sharding
Operating System: ALL
Participants:
Linked BF Score: 0

 Description   

geoNear command doesn't handle versioning correctly, so it will return duplicated or missing results if there is a concurrent chunk migration (or a shard has orphaned documents).



 Comments   
Comment by Esha Maharishi (Inactive) [ 07/Sep/17 ]

Reassigning to the sharding backlog and moving to the 'Safe Secondary Reads' epic as 3.5 desired.

If/when geoNear is fixed to be versioned (which should be a small change - just attach ChunkVersion::UNSHARDED() to the outgoing geoNear requests and/or move geoNear to use scatterGather()), the following safe secondary reads tests should be updated:

jstests/sharding/safe_secondary_reads_drop_recreate.js
jstests/sharding/safe_secondary_reads_single_migration_suspend_range_deletion.js
jstests/sharding/safe_secondary_reads_single_migration_waitForDelete.js

These tests all explicitly check that geoNear's behavior is unversioned.

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