[SERVER-58470] Investigate potential double-throw in ARM Created: 13/Jul/21  Updated: 27/Oct/23  Resolved: 14/Jul/21

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

Type: Improvement Priority: Major - P3
Reporter: Bernard Gorman Assignee: Drew Paroski
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Query Execution 2021-07-26
Participants:

 Description   

In SERVER-54937 we added an _assertNotInvalidated call in the AsyncResultsMerger to check whether a change stream cursor has been invalidated. This is called right before we schedule further getMores to the shards. We moved it here from AsyncResultsMerger::nextEvent() in SERVER-56871 since otherwise, a stream which does not return any events will never actually be invalidated.

However, we also call into this code path from the callback function that we assign to an asynchronous getMore, which are scheduled automatically as long as a valid opCtx exists and the previous batch received from the shard was empty. At a glance, it looks conceivable that this callback may throw while an exception thrown by another callback function or via this call in the BlockingResultsMerger is already active.

We should investigate whether it is possible to crash the process by inducing this scenario. If so, we'll need to rework our approach.



 Comments   
Comment by Bernard Gorman [ 14/Jul/21 ]

After looking into this further, we're satisfied that this situation cannot occur. Once a getMore has been dispatched via _scheduleGetMores, the automated retries proceed on a separate loop that does not go through _assertNotInvalidated again.

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