[SERVER-66000] Make post-downgrade retry error for retryable writes that are executed using internal transactions consistent Created: 27/Apr/22  Updated: 06/Dec/22  Resolved: 28/Apr/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: Cheahuychou Mao Assignee: [DO NOT USE] Backlog - Sharding NYC
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Sharding NYC
Participants:

 Description   

SERVER-58761 made setFVC do the following:

For each session that has an internal session that executed retryable internal transactions for a command with txnNumber (i.e. as indicated by its lsid.txnNumber) greater or equal to the latest txnNumber in the parent session, update the config.transactions entry for the parent session to have txnNumber equal to that lsid.txnNumber and lastWriteOpTime equal to {t: 1, ts: Timestamp(1, 0)}.

However, it didn't make setFCV unset/set the "state" field in the config.transactions entry for the parent session as part of that write. So a retry after a downgrade would get an IncompleteTransactionHistory with the message "Cannot retry a retryable write that has been converted into a transaction" if the previous txnNumber on the parent session corresponds to a transaction and "Incomplete history detected for transaction" if the previous txnNumber on the parent session corresponds to a retryable write. We should make it such that there can only be one kind of error message. One way to do is this to unset the "state" field or set it "committed".



 Comments   
Comment by Jack Mulrow [ 28/Apr/22 ]

This should be very unlikely for customer workloads to hit and is not a correctness issue, just a slightly confusing error message, so closing as won't fix.

Generated at Thu Feb 08 06:04:12 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.