-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Internal Code
-
None
-
Fully Compatible
-
ALL
-
Sharding 2019-02-11
We're using the failCommand fail point for the "Convenient API for Transactions" spec tests to return a write concern error on commitTransaction. The following shell script generally reproduces the issue we're encountering:
use admin; db.runCommand({ configureFailPoint: "failCommand", mode: { times: 2 }, data: { failCommands: ["insert"], closeConnection: false, writeConcernError: { code: 64, codeName: "WriteConcernFailed", errmsg: "waiting for replication did not time out" } } }); db.test.insert({ a: "something" }); db.test.insert({ b: "or_other" });
After investigating with mark.benvenuto, it appears that because closeConnection and writeConcernError are both specified, the fail point is activated twice: first here, then here.
If closeConnection: false is removed, or {{ mode: { times: 4 } }} is specified, then the fail point operates as expected.