[SERVER-63555] Investigate correct maxTimeMS behavior for per-shard cursors Created: 10/Feb/22  Updated: 10/Feb/22  Resolved: 10/Feb/22

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

Type: Task Priority: Major - P3
Reporter: Mickey Winters Assignee: Mickey Winters
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:

 Description   

during SERVER-62738 the maxTimeMS behavior we got out of the box is that mongos will swallow a network timeout and return an empty batch. The design currently says that in this senario an error should be returned, not an empty batch.

// using helpers from jstests/noPassthrough/change_streams_per_shard_cursor.js
[sdb, st, shardId] = startSharded(true);
c = pscWatch(sdb, "coll", shardId);
c._maxAwaitTimeMS = 10000;
st.shard0.adminCommand({configureFailPoint: 'waitAfterPinningCursorBeforeGetMoreBatch',
                        mode: 'alwaysOn', data: {nss: dbName+".coll"}});
assert(!c.isExhausted());
print("getting next");
c.hasNext(); // According to the design this should raise an error
print("got batch");
 
st.stop();



 Comments   
Comment by Mickey Winters [ 10/Feb/22 ]

Opened thread in design instead

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