[SERVER-66854] Reacquire locks for prepared transactions on step-up can crash the server Created: 28/May/22  Updated: 29/Oct/23  Resolved: 25/Aug/22

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

Type: Bug Priority: Major - P3
Reporter: Moustafa Maher Assignee: Vesselina Ratcheva (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2022-07-11, Repl 2022-08-08, Repl 2022-08-22, Repl 2022-09-05, Repl 2022-07-25
Participants:
Linked BF Score: 5

 Description   

On step-up, we scan all sessions and reacquire locks for prepared transactions.
to acquire these locks we create new operation contexts using these transactions's sessions, so if these sessions got killed the opCtx got terminated which will raise an exception.

We are calling this procedure from a no-except function that will crash the server.

Call stack:
1- ReplicationCoordinatorImpl::signalDrainComplete (noexcept)
    _externalState->onTransitionToPrimary(opCtx)

2- MongoDSessionCatalog::onStepUp(opCtx)

3- We create new opCtx to reacquire the locks to prepared txns with sessions that can be killed.



 Comments   
Comment by Britt Snyman [ 01/Sep/22 ]

Replacing the 6.1.0-rc1 fixVersion with 6.2.0-rc0 since these tickets had commits to master that were merged after we branched for v6.1.

Comment by Githook User [ 25/Aug/22 ]

Author:

{'name': 'Vesselina Ratcheva', 'email': 'vesselina.ratcheva@10gen.com', 'username': 'vessy-mongodb'}

Message: SERVER-66854 Prevent step-up ops from being killed by killSessions commands
Branch: master
https://github.com/mongodb/mongo/commit/5930149b09f51b1035b7a24556399a8777f9399c

Comment by Elizabeth Roytburd [ 31/May/22 ]

Replication does not currently have the bandwidth to address this so we are reassigning to Sharding to take a look. cc ratika.gandhi@mongodb.com 

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