Loading...

XML

Word

Printable

JSON

Type: Task
Resolution: Unresolved
Priority: Major - P3
Fix Version/s: None
Affects Version/s: None
Component/s: None
Labels:
None

Assigned Teams:

Storage Execution
CAR Domain/s:
None

Aha! Reference:
None
Tracking Level:
None
Risk Status:
None
Exec Notes:
None
Goal Name(s):
None
Goal Link:
None

It appears that some internal replicated collections may be written to before we step up and start the replicated fast count thread. This makes it difficult to guarantee that these values are correct (SERVER-119811 is one potential bug).

As an expedient short term fix, ~~SERVER-119821~~ disabled validation of the internal collection counts.

However, with a better sense of what collections are being written to before step up (and potentially a way to avoid this) it should be possible to have a more granular, well-defined policy around which writes we track and don't track.

depends on

SERVER-119811 Dirty writes that happen before step up get their metadata values overwritten at startup

Open

SERVER-119996 Secondary nodes will have incorrect fast size and count for collections that were populated on startup

Closed

is duplicated by

SERVER-120057 Initialize fast count collection before write to admin.system.version

Closed

is related to

SERVER-119811 Dirty writes that happen before step up get their metadata values overwritten at startup

Open

SERVER-119821 Do not enforce replicated fast count on internal collections

Closed

SERVER-119902 Replicated FastCount Find should always return a correct value

Closed

(1 is related to)

Assignee:: Unassigned
Reporter:: Damian Wasilewicz
Participants:: Damian Wasilewicz
Votes:: 0 Vote for this issue
Watchers:: 3 Start watching this issue

Created:: Feb 19 2026 09:10:10 PM UTC
Updated:: Feb 21 2026 01:30:03 AM UTC

Details

Description

Attachments

Issue Links

Activity

People

Dates