[SERVER-33113] Do not error on the presence of a 'state' field in a transactions table entry Created: 03/Feb/18  Updated: 29/Oct/23  Resolved: 16/May/18

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.0.0-rc0

Type: Task Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Siyuan Zhou
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-33138 Ensure that 4.0 binaries can interpre... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2018-05-07, Repl 2018-05-21
Participants:

 Description   

In 4.2 transaction table entries will have a 'state' field added. To be save upgrade/downgrade work in 4.2, we should be prepared to encounter transaction table entries with a 'state' field in 4.0. If the 'state' is 'committed', we should treat it the same as if there was no state field. If the 'state' field is anything other than 'committed', then we should treat it as though that transaction table entry doesn't exist.



 Comments   
Comment by Githook User [ 16/May/18 ]

Author:

{'email': 'siyuan.zhou@mongodb.com', 'username': 'visualzhou', 'name': 'Siyuan Zhou'}

Message: SERVER-33113 Make SessionTxnRecord IDL non-strict.
Branch: master
https://github.com/mongodb/mongo/commit/417673fd65eac197f4bc21aab5ae5791b272dbf2

Comment by Siyuan Zhou [ 15/May/18 ]

Discussed with spencer offline. The "state" field isn't the only issue for downgrade from 4.2 to 4.0. The oplog format will be different and retryable writes after downgrade will need to walk back through the oplog chain and crash after seeing unexpected formats. Thus we may need to clean the transaction table or force users to use new sessions. That makes the original problem in this description not relevant anymore.

We can also only support downgrade from 4.2 to a higher version of 4.0 so that we can add compatibility support in later minor versions of 4.0, when the 4.2 change becomes clear.

For upgrade, because 4.2 needs to support FCV 4.0, we have to keep the current logic and oplog format for mixed version replsets in FCV 4.0. When all nodes have been upgraded to 4.2, the FCV can be updated.

The only change needed in this ticket is to relax the IDL of transaction table to allow unexpected fields in 4.0 since the transaction table is only accessed internally and not directly by users.

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