[SERVER-82619] inReplicationRecovery flag recursive set/unset not well defined Created: 31/Oct/23 Updated: 22/Jan/24 |
|
| Status: | Open |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Yujin Kang Park | Assignee: | Backlog - Replication Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | repl-shortlist | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Replication
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
In multiple places, we follow the same pattern of setting inReplicationRecovery, plus instantiating a scope guard to unset it. Additionally, we recursively set the inReplicationRecovery flag, with each call having it's own scope guard to unset the flag. This means the inner scope guard is unsetting the flag while the parent expects the flag to still be set. (See FCBIS setting the flag and then recoverFromOplogAsStandalone calls recoverFromOplog, which also sets the flag). We should add a RAII type to avoid all this duplication, and ensure only the top level instance unsets the flag. |