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.