[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:
Depends
depends on SERVER-47568 No keys found for HMAC in RECOVERING ... Closed
Related
is related to SERVER-54167 configOpTime can become ahead of Vect... Closed
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 SERVER-47568). There is no concrete bug that is known to be caused by this.

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