[SERVER-27523] geo_s2cursorlimitskip.js fails in initial sync passthrough due to reads performed by the repl system Created: 27/Dec/16  Updated: 05/Apr/17  Resolved: 27/Dec/16

Status: Closed
Project: Core Server
Component/s: Querying, Replication
Affects Version/s: None
Fix Version/s: 3.4.2, 3.5.2

Type: Bug Priority: Major - P3
Reporter: James Wahlin Assignee: James Wahlin
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Query 2017-01-23
Participants:
Linked BF Score: 0

 Description   

The geo_s2cursorlimitskip.js test makes assertions about the number of query and getMore operations performed against a particular collection. This is invalid in our initial sync passthrough suite, core_small_oplog_rs_initsync. When an initial sync occurs during the execution of the test, the downstream node will issue a find command against its sync source in order to clone the data. From the sync source's perspective, this read looks just like any user-issued find, and it will be counted by the operation latency histogram. This causes the read count to be higher than expected by the test.



 Comments   
Comment by Githook User [ 27/Dec/16 ]

Author:

{u'username': u'jameswahlin', u'name': u'James Wahlin', u'email': u'james.wahlin@10gen.com'}

Message: SERVER-27523 blacklist geo_s2cursorlimitskip.js from background initial sync passthru

(cherry picked from commit 72112a72ec3ee48cb883fc02b2904079d11f4954)
Branch: v3.4
https://github.com/mongodb/mongo/commit/cafed1b32d4ae2cf615b8ec0085dcebd4bd45404

Comment by Githook User [ 27/Dec/16 ]

Author:

{u'username': u'jameswahlin', u'name': u'James Wahlin', u'email': u'james.wahlin@10gen.com'}

Message: SERVER-27523 blacklist geo_s2cursorlimitskip.js from background initial sync passthru
Branch: master
https://github.com/mongodb/mongo/commit/72112a72ec3ee48cb883fc02b2904079d11f4954

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