When a retryable update would update a document's shard key, we manually convert the update to a transaction with a delete and insert op (this feature was written prior to the existence of internal transactions). The stmtId in each write request will end up being populated with the default of '0' - in standard transactions stmtId doesn't matter. This becomes a problem when the original update is an FLE update however - FLE uses retryable internal transactions, where stmtIds do matter - the reuse of stmtId for the transaction will cause the entire update to fail.

Potential options to fix this -

• Change the code path for updates to a doc's shard key to use retryable internal transactions. There is code currently behind a failpoint to do this - the work was done as a part of the internal transactions project, and wasn't fully completed.
• Change the current implementation of the code path for updates to a doc's shard key to set different stmtIds.