When migration thread updates the session table while the session has been checked out by a retryable write, only one of them will succeed due to the write conflict on the same _id (session id). Compare-and-swap style update and generating WCE manually seems unnecessary because storage engine should be able to generate those WriteConflictExceptions.

This issue makes more than one write with snapshot isolation throw WCE because the in-memory _lastWrittenSessionRecord will be updated at the commit time of the transaction and is out of sync after the first write. CAS update cannot find the expected (stale) original doc.

When multi-statement transaction is implemented this won't be a problem since we don't support retryable writes for operations during a transaction. But I still think it's an opportunity to improve the code. Another benefit is to use idHack in query planning, which doesn't have the CAS update performance issue in SERVER-31845 and keeps the code clearer.