-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Optimization
-
ALL
-
Programmability 2025-11-24
-
None
-
None
-
None
-
None
-
None
-
None
-
None
In ReplicaSetNodeProcessInterface::_executeCommandOnPrimary, the callback version of TaskExecutor::scheduleRemoteCommand is used incorrectly because it incorrectly assumes callbacks are not run on shutdown.
I think the logic here attempts to block on scheduleRemoteCommand.
executor::RemoteCommandRequest request(std::move(hostAndPort), ns.dbName(), cmd.obj(), opCtx); auto [promise, future] = makePromiseFuture<executor::TaskExecutor::RemoteCommandCallbackArgs>(); auto promisePtr = std::make_shared<Promise<executor::TaskExecutor::RemoteCommandCallbackArgs>>( std::move(promise)); auto scheduleResult = taskExecutor->scheduleRemoteCommand( std::move(request), [promisePtr](const auto& args) { promisePtr->emplaceValue(args); }); if (!scheduleResult.isOK()) { // Since the command failed to be scheduled, the callback above did not and will not run. // Thus, it is safe to fulfill the promise here without worrying about synchronizing access // with the executor's thread. promisePtr->setError(scheduleResult.getStatus()); } auto response = future.getNoThrow(opCtx);
This errors because we don't check for canceled CallbackArgs inside our callback.
I think we can just use the future returning variant of scheduleRemoteCommand, which will handle cancellation internally.