SERVER-126254 addressed a bug where, if an oplog entry was applied but not yet durable when fsyncLock acquired the global lock, the in-memory durableOpTime remained behind lastWritten for the duration of the lock. Consequently, lastCommittedOpTime could not advance, causing snapshot or majority reads with a later afterClusterTime to hang until fsyncUnlock was called.

The original fix was reverted because it advanced durableOpTime for writes that were not guaranteed to survive startup recovery. Since recovery unconditionally truncates the oplog at the oplog truncate-after point, this could allow a node to acknowledge or majority-commit an entry that would later be truncated after restart. BF-45325 demonstrated this failure mode. We need to implement a recovery-safe fix for the original issue without falsely advancing durability.

Acceptance criteria

• fsyncLock no longer leaves durableOpTime permanently behind lastWritten.
• No write is acknowledged or majority-committed unless it survives startup recovery.
• Oplog truncate-after-point handling remains consistent with any durable-optime advancement.
• Add a regression test covering the recovery/rollback scenario.