[SERVER-48527] Aborting in-progress transactions on step-up should clear session state before returning Created: 01/Jun/20  Updated: 29/Oct/23  Resolved: 10/Jun/20

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.4.0-rc10, 4.2.9, 4.7.0

Type: Bug Priority: Major - P3
Reporter: Judah Schvimer Assignee: Judah Schvimer
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Problem/Incident
causes SERVER-48729 Don't duplicate maxNumberOfTransactio... Closed
Related
related to SERVER-49459 Check sticky state on OperationContex... Closed
is related to SERVER-48600 RefineCollectionShardKey does not che... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.4, v4.2
Sprint: Repl 2020-06-15
Participants:
Linked BF Score: 11

 Description   

Step-up can run further operations on the same operation context, which will be left with session metadata (lsid, txnNumber, etc.) from the last transaction the node aborted as part of step-up.

These operations can then invariant that the session is not checked out even though they have session metadata on their operation context. Ordinarily they would exit early for not having a stmtId here. That stmtId is assigned here from the update request, which comes from here. That would return an uninitialized stmtId, except the txnNumber is not null like it should be here.



 Comments   
Comment by Githook User [ 25/Jun/20 ]

Author:

{'name': 'Judah Schvimer', 'email': 'judah@mongodb.com', 'username': 'judahschvimer'}

Message: SERVER-48527 Aborting in-progress transactions on step-up should clear session state before returning
Branch: v4.2
https://github.com/mongodb/mongo/commit/f43c336b61fcf493510080807937870db4ed75ba

Comment by Githook User [ 17/Jun/20 ]

Author:

{'name': 'Judah Schvimer', 'email': 'judah@mongodb.com', 'username': 'judahschvimer'}

Message: SERVER-48527 Aborting in-progress transactions on step-up should clear session state before returning

(cherry picked from commit 07169364c2aece0fb99f4a97b796196edb033efa)
Branch: v4.4
https://github.com/mongodb/mongo/commit/e5a25068d1e122488ea5e8d400e86e96022e4c72

Comment by Githook User [ 10/Jun/20 ]

Author:

{'name': 'Judah Schvimer', 'email': 'judah@mongodb.com', 'username': 'judahschvimer'}

Message: SERVER-48527 Aborting in-progress transactions on step-up should clear session state before returning
Branch: master
https://github.com/mongodb/mongo/commit/07169364c2aece0fb99f4a97b796196edb033efa

Comment by Siyuan Zhou [ 09/Jun/20 ]

judah.schvimer, I think we should backport this to 4.2 since it's used by large transactions as you mentioned.

Comment by Githook User [ 09/Jun/20 ]

Author:

{'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}

Message: Revert "SERVER-48527 Aborting in-progress transactions on step-up should clear session state before returning"

This reverts commit c7c78598d530710b1e0c8805bfceb37ccde08604.
Branch: master
https://github.com/mongodb/mongo/commit/9a41a3c8f69fae56bb23d1d6004d7f75ff7ce9fa

Comment by Judah Schvimer [ 08/Jun/20 ]

siyuan.zhou, should I backport this to 4.2? It's not strictly necessary, but has to do with Large Transactions.

Comment by Githook User [ 08/Jun/20 ]

Author:

{'name': 'Judah Schvimer', 'email': 'judah@mongodb.com', 'username': 'judahschvimer'}

Message: SERVER-48527 Aborting in-progress transactions on step-up should clear session state before returning
Branch: master
https://github.com/mongodb/mongo/commit/c7c78598d530710b1e0c8805bfceb37ccde08604

Comment by Judah Schvimer [ 04/Jun/20 ]

This test is somewhat blocked by SERVER-48600. Thinking of how to sequence this all and not block it on that.

Comment by Judah Schvimer [ 01/Jun/20 ]

I think that the cleanest way to do this is for aborting in progress transactions to use AlternativeClientRegions.

Comment by Judah Schvimer [ 01/Jun/20 ]

This was introduced in 4.4, since that was when Refine Document Shard Key was introduced. That said, backporting to 4.2 is likely a good idea since it's possible this could trigger an invariant with other step-up writes that we just haven't seen yet.

Generated at Thu Feb 08 05:17:23 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.