-
Type: Bug
-
Resolution: Won't Do
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Networking & Observability
-
ALL
-
200
After this change to pass a cancellation source into where we wait for responses from the async response sender, we got some interesting BFs (example) where the async request sender would segfault while trying to resolve the targeter due to the opCtx the targeter is using having no client set. It is a bit confusing for us because the opCtx we are passing to the targeter seems to always be created with a client and there isn't an obvious way to unset a client in an opCtx.
We were wondering whether there is something about not waiting for the async response sender's responses that breaks the opCtx somehow? It seemed possible that the opCtx got destroyed at some point before the sendCommand (which runs on an executor) completed, but it seemed surprising that the opCtx was still a valid pointer with just the client pointer set to nullptr if that were the case
(gdb) p opCtx
$1 = (mongo::OperationContext *) 0x51a2f5e61900
(gdb) p opCtx->_client
$2 = (mongo::Client * const) 0x0
(gdb)
- is depended on by
-
SERVER-95485 sendAuthenticatedCommandToShards should be interruptible while waiting for responses
- Open
- related to
-
SERVER-78524 async_rpc util getAllResponsesOrFirstErrorWithCancellation can leave dangling continuations
- Closed