-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: 7.0.0, 8.0.0, 9.0.0-rc0, 8.3.0
-
Component/s: None
-
None
-
Catalog and Routing
-
Fully Compatible
-
ALL
-
v9.0, v8.3, v8.0, v7.0
-
CAR Team 2026-07-20
-
2
-
🟥 DDL
-
None
-
None
-
None
-
None
-
None
-
None
A sharded time-series collMod can leave shard participant critical sections held if it hits a non-retriable error after the kBlockShards phase.
CollModCoordinator enters the critical section in kBlockShards by sending _shardsvrParticipantBlock with ReadsAndWrites to shards owning chunks. It only releases that critical section later as a side effect of _shardsvrCollModParticipant in kUpdateShards, when the participant sees needsUnblock=true and calls ShardingRecoveryService::releaseRecoverableCriticalSection().
There is no dedicated ReleaseCritSec phase and no collMod-specific _cleanupOnAbort() path. If a non-retriable error occurs after kBlockShards but before all participant _shardsvrCollModParticipant commands successfully release their critical sections, the coordinator can abort. The existing non-retriable error handling resumes migrations, but it does not send an unblock command or otherwise release the recoverable critical sections.
Result: CRUD may remain blocked on affected shards even though the collMod coordinator has aborted.
- is related to
-
SERVER-132808 collMod should do all global/authoritative catalog changes under the critical section
-
- Backlog
-
-
SERVER-110653 Investigate removing/reducing the CRUD block during granularity changes on timeseries
-
- Closed
-
- related to
-
SERVER-131459 Simplify collmod coordinator by adding additional phases
-
- Backlog
-