[SERVER-63381] Relax optime.js test to account for wallClockTimes move backward. Created: 07/Feb/22 Updated: 29/Oct/23 Resolved: 23/Feb/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 5.3.0-rc2 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Moustafa Maher | Assignee: | Moustafa Maher |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Sprint: | Repl 2022-02-21, Repl 2022-03-07 | ||||
| Participants: | |||||
| Linked BF Score: | 15 | ||||
| Description |
|
I think we are not utilizing the wallClockTime in any consistency related places and we only depends on the opTime which is the cluster causal logical timestamp which encounter the possibility that the wallClockTime can go back in time.
So for this ticket we are going to only relax the test. |
| Comments |
| Comment by Githook User [ 23/Feb/22 ] |
|
Author: {'name': 'Moustafa Maher Khalil', 'email': 'm.maher@mongodb.com', 'username': 'moustafamaher'}Message: |
| Comment by Moustafa Maher [ 19/Feb/22 ] |
|
We use it also to determine if the preImage is expired or not ( also safe). |
| Comment by Moustafa Maher [ 19/Feb/22 ] |
|
I see that we use it also as a lastWrite for SessionTxnRecord and then use this timestamp to decide whether to reap the session or not (MongoDSessionCatalog::reapSessionsOlderThan). This is also safe as the worst that can happen is that the session will be closed sooner. |
| Comment by Moustafa Maher [ 14/Feb/22 ] |
|
I've revised the paper for ClusterTime ticking algorithm and we already handle the case the that the wallClock can go backward, which matches our code.
|