Q. Re-startup Hidden node with {secondaryDelaySecs: 3600}

I was doing the test as below.

  1. Add 1 node to 3 nodes replica set.
    { priority: 0, hidden: true, secondaryDelaySecs: 3600(1h) }

  2. RESTORE dump data into primary node.

  3. When RESTORE is complete, all nodes shutdown.

  4. Wait for 3 hours.

  5. All nodes startup.

  6. Check hidden node status at this time.

The results of this test were disappointing.
It did not change from the following state to secondary, and the logs as below were repeated.

rs0:RECOVERING>

{“t”:{"$date":“2022-04-25T13:13:59.598+09:00”},“s”:“I”, “c”:"-", “id”:4939300, “ctx”:“monitoring-keys-for-HMAC”,“msg”:“Failed to refresh key cache”,“attr”:{“error”:“ReadConcernMajorityNotAvailableYet: Read concern majority reads are currently not possible.”,“nextWakeupMillis”:13000}}

{“t”:{"$date":“2022-04-25T13:14:03.318+09:00”},“s”:“I”, “c”:“STORAGE”, “id”:22430, “ctx”:“Checkpointer”,“msg”:“WiredTiger message”,“attr”:{“message”:"[1650860043:318063][658:0x7f40d490f700], WT_SESSION.checkpoint: [WT_VERB_CHECKPOINT_PROGRESS] saving checkpoint snapshot min: 23, snapshot max: 23 snapshot count: 0, oldest timestamp: (1650850686, 1) , meta checkpoint timestamp: (1650850686, 1) base write gen: 95"}}

{“t”:{"$date":“2022-04-25T13:14:04.333+09:00”},“s”:“I”, “c”:“REPL”, “id”:21799, “ctx”:“BackgroundSync”,“msg”:“Sync source candidate chosen”,“attr”:{“syncSource”:“10.64.40.50:27017”}}

{“t”:{"$date":“2022-04-25T13:14:04.334+09:00”},“s”:“I”, “c”:“REPL”, “id”:5579708, “ctx”:“ReplCoordExtern-0”,“msg”:“We are too stale to use candidate as a sync source. Denylisting this sync source because our last fetched timestamp is before their earliest timestamp”,“attr”:{“candidate”:“10.64.40.50:27017”,“lastOpTimeFetchedTimestamp”:{"$timestamp":{“t”:1650850686,“i”:1}},“remoteEarliestOpTimeTimestamp”:{"$timestamp":{“t”:1650851355,“i”:5143}},“denylistDurationMinutes”:1,“denylistUntil”:{"$date":“2022-04-25T04:15:04.334Z”}}}

{“t”:{"$date":“2022-04-25T13:14:04.334+09:00”},“s”:“I”, “c”:“REPL”, “id”:21799, “ctx”:“ReplCoordExtern-0”,“msg”:“Sync source candidate chosen”,“attr”:{“syncSource”:“10.64.40.40:27017”}}

{“t”:{"$date":“2022-04-25T13:14:04.334+09:00”},“s”:“I”, “c”:“REPL”, “id”:5579708, “ctx”:“ReplCoordExtern-0”,“msg”:“We are too stale to use candidate as a sync source. Denylisting this sync source because our last fetched timestamp is before their earliest timestamp”,“attr”:{“candidate”:“10.64.40.40:27017”,“lastOpTimeFetchedTimestamp”:{"$timestamp":{“t”:1650850686,“i”:1}},“remoteEarliestOpTimeTimestamp”:{"$timestamp":{“t”:1650851352,“i”:6137}},“denylistDurationMinutes”:1,“denylistUntil”:{"$date":“2022-04-25T04:15:04.334Z”}}}

{“t”:{"$date":“2022-04-25T13:14:04.334+09:00”},“s”:“I”, “c”:“REPL”, “id”:21799, “ctx”:“ReplCoordExtern-0”,“msg”:“Sync source candidate chosen”,“attr”:{“syncSource”:“10.64.40.30:27017”}}

{“t”:{"$date":“2022-04-25T13:14:04.335+09:00”},“s”:“I”, “c”:“REPL”, “id”:5579708, “ctx”:“ReplCoordExtern-0”,“msg”:“We are too stale to use candidate as a sync source. Denylisting this sync source because our last fetched timestamp is before their earliest timestamp”,“attr”:{“candidate”:“10.64.40.30:27017”,“lastOpTimeFetchedTimestamp”:{"$timestamp":{“t”:1650850686,“i”:1}},“remoteEarliestOpTimeTimestamp”:{"$timestamp":{“t”:1650851357,“i”:1278}},“denylistDurationMinutes”:1,“denylistUntil”:{"$date":“2022-04-25T04:15:04.335Z”}}}

{“t”:{"$date":“2022-04-25T13:14:04.335+09:00”},“s”:“I”, “c”:“REPL”, “id”:21798, “ctx”:“ReplCoordExtern-0”,“msg”:“Could not find member to sync from”}

What is the cause?