[SERVER-58357] [ephemeralForTest] TemporaryKVRecordStore fails to register commit handler in WCE loop Created: 07/Jul/21  Updated: 29/Oct/23  Resolved: 15/Jul/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 5.0.2, 5.1.0-rc0

Type: Bug Priority: Major - P3
Reporter: Benety Goh Assignee: Benety Goh
Resolution: Fixed Votes: 0
Labels: EFT
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Related
is related to SERVER-50293 TemporaryKVRecordStore should reset t... Closed
is related to SERVER-57231 [ephemeralForTest] index build cleanu... Closed
is related to SERVER-38397 make WiredTigerRecoveryUnit::State a ... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v5.0
Sprint: Execution Team 2021-07-26
Participants:
Linked BF Score: 20

 Description   

In SERVER-57231, we updated the finalization logic in TemporaryKVRecordStore so that the finalization flag is updated in a commit handler when we are running within a WriteConflictException retry loop with an active WriteUnitOfWork.

However, the RecoveryUnit in a ephemeralForTest storage engine never returns true for the RecoveryUnit::isActive() function. The implementation transitions the internal state to kInactiveInUnitOfWork but never makes to Active. Most of the server code that queries the active state only cares about !isActive() so this is generally not an issue for test deployments using the ephemeralForTest storage engine.

The impact of this defect is limited to server instances running the non-production ephemeralForTest storage engine.



 Comments   
Comment by Vivian Ge (Inactive) [ 06/Oct/21 ]

Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you!

Comment by Githook User [ 22/Jul/21 ]

Author:

{'name': 'Benety Goh', 'email': 'benety@mongodb.com', 'username': 'benety'}

Message: SERVER-58357 transition EFT RecoveryUnit state to active when there are pending modifications

Previously, we would leave the EFT RecoveryUnit in an inactive-but-in-UOW state which
still allows us to commit and rollback the WriteUnitOfWork successfully. However, for
code that has conditional logic based on checking RecoveryUnit::isActive(), this may
result in behavior that would deviate from a server running with the WiredTiger storage
engine.

(cherry picked from commit 8b10fbf556eaad5a7b0379e47ab774f6d1df3228)
Branch: v5.0
https://github.com/mongodb/mongo/commit/c203b21711233ede56337cd9ed8b2c67e9af461a

Comment by Githook User [ 14/Jul/21 ]

Author:

{'name': 'Benety Goh', 'email': 'benety@mongodb.com', 'username': 'benety'}

Message: SERVER-58357 transition EFT RecoveryUnit state to active when there are pending modifications

Previously, we would leave the EFT RecoveryUnit in an inactive-but-in-UOW state which
still allows us to commit and rollback the WriteUnitOfWork successfully. However, for
code that has conditional logic based on checking RecoveryUnit::isActive(), this may
result in behavior that would deviate from a server running with the WiredTiger storage
engine.
Branch: master
https://github.com/mongodb/mongo/commit/8b10fbf556eaad5a7b0379e47ab774f6d1df3228

Comment by Benety Goh [ 07/Jul/21 ]

The RecoveryUnit state should generally follow this transition graph.

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