Force fsync on sync source before initiating-set stable timestamp check

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Won't Fix
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Replication
    • ALL
    • v9.0
    • Repl 2026-08-03
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      We have identified a narrow mixed-version scenario during initial sync:

      1. Initiate a newly replica set.
      2. Downgrade FCV shortly afterward.
      3. Do so before the sync source has taken a checkpoint since initialization.
      4. Add a new node on the lower binary
      5. Let that new node initial sync from the sync source which will take the initiating skip as last checkpoint is pointing to the initialization.

      In this case, the initial syncing node can observe FCV state that is inconsistent with what its binary can safely interpret and crash very early in initial sync.
      This scenario is exercised in our multi-version testing.

      Production relevance

      This appears to be rare in production because it requires a very small timing window between replica set initialization, FCV downgrade, and initial sync before checkpoint. However, it is realistic enough that we should harden the product behavior rather than treat it as purely a test artifact.

      The scenario is recoverable by retrying initial sync, but the current failure is abrupt and the error message is not very actionable.

            Assignee:
            Moustafa Maher
            Reporter:
            Moustafa Maher
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: