[SERVER-76365] sharded_sort.js can leave unused mock responses to metadata cursors on mongotmock Created: 20/Apr/23  Updated: 29/Oct/23  Resolved: 02/May/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.1.0-rc0, 7.0.0-rc1

Type: Bug Priority: Major - P3
Reporter: George Wangensteen Assignee: Ben Shteinfeld
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Assigned Teams:
Query Optimization
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v7.0
Sprint: QO 2023-05-15
Participants:
Linked BF Score: 129

 Description   

This test schedules multi-cursor responses to be received from a mocked-mongot before an aggregation is run. In many cases, the additional response-cursor received is a metadata cursor. The test then sets up mock responses for getMores that it expects mongod to send to the mock. However, because the aggregation sent by the user to mongod doesn't require any use of the metadata, the cursor can be destroyed on mongod after the query is completed, before the getMore for the metadata reaches the network/the mock mongot. This timing issue is made more likely with the addition of pinned-connections; when pinning is enabled, commands for cursors returned from the same initial are serialized because they need to use the same connection, so it's increasingly likely that the user query can be completed (because the cursor containing the actual data is exhausted/getMore'd first) before the metadata cursor's getMore is scheduled. 

The result of this is that while assertions around the aggregation still work fine (this is legal behavior and doesn't represent a real bug), the mock-response we scheduled on the mongotmock is found when we tear down the test. As part of the teardown, we assert that no remaining responses are scheduled on the mocks, and this assertion fails. 


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