[SERVER-54281] VectorClock's configTime can become greater than clusterTime after a signature failure Created: 04/Feb/21 Updated: 06/Dec/22 Resolved: 07/Jul/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jordi Serra Torrens | Assignee: | [DO NOT USE] Backlog - Sharding EMEA |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Sharding EMEA
|
||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Sprint: | Sharding EMEA 2022-06-13, Sharding EMEA 2022-06-27 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
If the key to sign the clusterTime was not available, VectorClock::SignedComponentFormat::out will not write it to the BSON builder and will return false. Then VectorClock::gossipOut may have built $configTime and $topologyTime, but not $clusterTime, and thus return false. Finally, VectorClockMetadataHook::writeRequestMetadata will write only $configTime and $topologyTime to the request. The receiving node will then possibly advance it's VectorClock::configTime but not the clusterTime. So configTime could become ahead of clusterTime. |
| Comments |
| Comment by Jordi Serra Torrens [ 01/Jul/22 ] |
|
This situation still exists. It has been reproduced with this patch that adds invariants. This situation is believed to be transient and only possibly occur during startup (see |