[SERVER-37358] ARS shouldn't return while targeting is outstanding Created: 27/Sep/18  Updated: 29/Oct/23  Resolved: 01/Oct/18

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

Type: Bug Priority: Major - P3
Reporter: Mira Carey Assignee: Mira Carey
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-37330 Add sharded passthrough suites to det... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Service Arch 2018-10-08
Participants:
Linked BF Score: 0

 Description   

As part of SERVER-35689, Replica set targeting was made async (but with blocking in the ARS). But when we block on the returned future, we do so via an opctx which isn't marked uninterruptible (https://github.com/mongodb/mongo/commit/a276b7b1d0cc1d8d1e35bc0a222d2b2cce64bf43#diff-00d70c3e68a7ef394d6fccee5532e7e7R300) this means that opctx killing, or timing out, during scheduling leaves dangling references to the ARS and the baton in the ARS destructor. This in turn causes the invariant inside the baton to trigger.

I believe that the fix for now should involve making that an uninterruptible wait



 Comments   
Comment by Githook User [ 01/Oct/18 ]

Author:

{'name': 'Jason Carey', 'email': 'jcarey@argv.me', 'username': 'hanumantmk'}

Message: SERVER-37358 dont early return from ARS

As part of SERVER-35689, Replica set targeting was made async (but with
blocking in the ARS). But when we block on the returned future, we do
so via an opctx which isn't marked uninterruptible.

This means that opctx killing, or timing out, during scheduling leaves
dangling references to the ARS and the baton in the ARS destructor.
This in turn causes the invariant inside the baton to trigger.

The fix for now is to make that an uninterruptible wait
Branch: master
https://github.com/mongodb/mongo/commit/b757d87fc622d44b16013e2722832a655d7ca052

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