[nos-a]

Backport of #13841 to release-7.4. rdar://186610406

Problem

After a protocol upgrade, global-configuration history can contain entries serialized by an older protocol. The cluster controller replaced that history with a maximum-version sentinel, allowing a refresh to accept an older cached GRV-proxy snapshot and permanently miss the latest committed configuration update.

Change

The cluster controller publishes the committed version (decoded from the durable versionstamp) in the replacement history entry, and GlobalConfig::refresh rejects snapshots older than the largest seen version. Includes both unit tests from the original change.

release-7.4 differences: GlobalConfig is still an ACTOR here, so the refresh change and the stale-snapshot regression test are ported to ACTOR/wait/state syntax. The conflict was confined to GlobalConfig.actor.cpp.

Testing

• Release build in the Okteto pod; /fdbclient/GlobalConfig/RejectsStaleRefreshSnapshot and /fdbserver/clustercontroller/globalConfigProtocolChangeUsesCommittedVersion pass via fdbserver -r unittests -f.
• clang-format-19: clean.
• 100k Joshua ensemble 20261026-210837-kostia-ea7b2fae5d5db9d7 on this commit (-F 100): pass=99997 fail=3 runtime=3:24:59.
  • 2 failures are exit -15 with no test file or error (agent infrastructure noise).
  • 1 failure is tests/slow/BackupOldAndNewRestore.toml seed 1033057815 (-b off), timed_out at 5401 simulated seconds; it reproduces on the same binary. The new backup stays Running and never becomes restorable after heavy recovery churn (275 backup worker recruitments, injected io_error BackupFailed events, repeated NoPrimaryPeekLocationForLR). The run contains no GlobalConfigRefreshStaleSnapshot events, and the changed cluster-controller path only runs on a protocol change, which this test does not exercise. I did not run a baseline release-7.4 build, so I have not proven it is pre-existing; at 1 in 100k it is not attributed to this change.

[spraza]

@saintstack can one of you also review?

[foundationdb-ci]

Result of foundationdb-pr-clang on Linux RHEL 9

• Commit ID: 5bed1a4
• Duration 0:39:03
• Result: ✅ SUCCEEDED
• Error: N/A
• Build Log terminal output (available for 30 days)
• Build Workspace zip file of the working directory (available for 30 days)

[foundationdb-ci]

Result of foundationdb-pr-clang-arm on Linux RHEL 9

• Commit ID: 5bed1a4
• Duration 0:43:21
• Result: ✅ SUCCEEDED
• Error: N/A
• Build Log terminal output (available for 30 days)
• Build Workspace zip file of the working directory (available for 30 days)

[foundationdb-ci]

Result of foundationdb-pr on Linux RHEL 9

• Commit ID: 5bed1a4
• Duration 0:56:11
• Result: ✅ SUCCEEDED
• Error: N/A
• Build Log terminal output (available for 30 days)
• Build Workspace zip file of the working directory (available for 30 days)

[foundationdb-ci]

Result of foundationdb-pr-macos-m1 on macOS 14.x

• Commit ID: 5bed1a4
• Duration 1:00:23
• Result: ✅ SUCCEEDED
• Error: N/A
• Build Log terminal output (available for 30 days)
• Build Workspace zip file of the working directory (available for 30 days)

[foundationdb-ci]

Result of foundationdb-pr-cluster-tests on Linux RHEL 9

• Commit ID: 5bed1a4
• Duration 1:43:38
• Result: ✅ SUCCEEDED
• Error: N/A
• Build Log terminal output (available for 30 days)
• Build Workspace zip file of the working directory (available for 30 days)
• Cluster Test Logs zip file of the test logs (available for 30 days)

[foundationdb-ci]

Result of foundationdb-pr-macos on macOS 14.x

• Commit ID: 5bed1a4
• Duration 1:58:56
• Result: ✅ SUCCEEDED
• Error: N/A
• Build Log terminal output (available for 30 days)
• Build Workspace zip file of the working directory (available for 30 days)