[SERVER-50351] Add an invariant to make sure that the unprepared transactions can stash the transaction lock resources in PRIMARY style only if the node state is PRIMARY Created: 18/Aug/20  Updated: 06/Dec/22

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

Type: Task Priority: Major - P3
Reporter: Suganthi Mani Assignee: Backlog - Replication Team
Resolution: Unresolved Votes: 0
Labels: former-quick-wins
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Replication
Sprint: Repl 2020-10-05, Repl 2020-10-19, Repl 2020-11-02, Repl 2020-11-16
Participants:
Linked BF Score: 0

 Description   

We should add an invariant check over here to make sure that unprepared transactions can stash the transaction resource  in PRIMARY style only if the node state is PRIMARY)



 Comments   
Comment by Suganthi Mani [ 17/Nov/20 ]

Adding invariant work is an extra sanity check to avoid any future bugs like BF-18301 (step down misses killing some unprepared transactions).Luckily, this bug got fixed by SERVER-47645 (invalidates all session at the end of step down, which in-turn kills all leaked unprepared transactions). So, I would say if adding an invariant requires lots of code changes, it's ok to close the ticket without fix. Moving back to Needs Scheduling.

steven.vannelli, It was assigned back to me for investigation to clarify the purpose of the ticket. I don't have any WIP patch for this invariant.

Comment by Suganthi Mani [ 18/Aug/20 ]

Note: This work came out of this BF investigation. Failure to guarantee the above promise while stashing the transaction resource was leading to a complicated deadlock.

In order to have this invariant to pass, I think we should make that killSessionsAbortUnpreparedTransactions kills the active/inactive multi-document transactions with transaction state kNone (HINT: session->currentOperation()->inMultiDocumentTransaction) kInProgress by doing changes to this filter.

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