Loading...
Loading...
FailCommands enabled only for the `find` command are activated by retryable writes because retryable writes send an internal find command against`config.transactions`, which activates the failCommand. This is visible to the write command if the failCommand is configured with blockTimeMS and blockConnection because the triggered failCommand blocks the find for blockTimeMS, which in turn blocks the write by blockTimeMS. As a potential fix, Max Hirschorn suggested: probably we should check in shouldActivateFailCommandFailPoint() for Client::isInDirectClient() and not activate the failpoint for the internal find command.
JIRAUSER1270969 commented on Wed, 7 May 2025 09:29:50 +0000: Default behavior of the failpoint is unchanged, but we have added failDirectClientCommands option that can be set to false to prevent such failures. xgen-internal-githook commented on Tue, 6 May 2025 16:14:01 +0000: Author: {'name': 'Ivan Fefer', 'email': 'ivan.fefer@mongodb.com', 'username': 'Fefer-Ivan'} Message: SERVER-96164 Check for direct client in shouldActivateFailCommandFailPoint (#34509) GitOrigin-RevId: 8a7ae765120bb7cdf9a5838be915172fa94441ec Branch: master https://github.com/mongodb/mongo/commit/2c0672bc19f56f829f91f023717acd11294c73f1
Configure a failCommand for `find`, specifying blockTimeMS and blockConnection: true: { configureFailPoint: 'failCommand', mode: { times: 1 }, data: { failCommands: ['find'], blockConnection: true, blockTimeMS: 10_000 } } execute a retryable write and observe the command is delayed by blockTimeMS. disable retryable writes and observe that the command is instantaneous.
Click on a version to see all relevant bugs
MongoDB Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.