Unfortunately I don't have a small test case that reproduces the error, but a write conflict can be reproduced by running the `agg_match.js` FSM concurrency test with an increased write conflict activation probability: 1. Change `jstests/concurrency/fsm_all.js` to call `runWorkLoadsSerially` on an array only containing "jstests/concurrency/fsm_workloads/agg_match.js" (instead of `ls(dir)` 2. In the function `setupWorkload` in `jstests/concurrency/fsm_libs/runner.js`, add the line `assert.commandWorked(myDB.adminCommand({configureFailPoint: "WTWriteConflictException", mode: {activationProbability: 0.0005}}));` (right after the declaration of the variable `myDB`) 3. Run resmoke with `--repeat=10 --executor=conncurrency jstests/concurrency/fsm_all.js`. A write conflict will occur within the first five or so iterations.