Preserve committed global configuration versions across protocol upgrades

[tclinkenbeard-oai]

Problem

After a protocol upgrade, global-configuration history can contain entries serialized by an older protocol. The cluster controller currently replaces 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.

For the paired ClientTransactionProfilingCorrectness restart test, stale profiling settings can keep server roles writing profiling data after sampling is disabled, preventing the storage queue from draining.

Change

• Decode the committed global-configuration version from its durable versionstamp when incompatible history requires a full refresh.
• Publish that committed version in the replacement history entry so existing refresh logic waits for a sufficiently fresh GRV-proxy snapshot.
• Add a focused cluster-controller regression for the committed-version fallback.

Validation

• fdbserver_clustercontroller_test: 30 tests passed.
• Paired tests/restarting/from_7.3.29/ClientTransactionProfilingCorrectness-{1,2}.toml restart from 7.3.43: reproduced the failure before the change; both phases passed after the change.
• Independent paired restart from 7.4.5: the previously failing case passes after the change.
• Fault injection remains enabled, with buggify enabled for phase one and disabled for phase two.
• Profiling maintenance after sampling was disabled dropped from 242 operations to zero, and the outstanding storage queue drained from 11,098 bytes to zero.

[tclinkenbeard-oai]

Generated by Codex.

What is it trying to do?

Prevent protocol upgrades from applying stale global-configuration snapshots by preserving the committed configuration version and rejecting outdated GRV-proxy responses before they affect client state.

Is it correct?

Yes, based on inspection. The durable versionstamp decoding matches existing GRV-proxy behavior and historical 7.3/7.4 formats. The client rejects stale responses before applying configuration or invoking callbacks, while preserving cancellation, retries, and legacy sentinel behavior.

Both added regression tests exercise their intended failure modes.

Current-head clang-format, clang-tidy, Windows, builder, and cluster checks have all passed. No builds or tests were run during this independent review.

Are there bugs?

I did not find any correctness bugs.

Are there omissions?

The PR description does not mention the new client-side freshness check or its fdbclient_test regression. This is nonblocking.

Are there better ways of doing things?

No changes recommended. Checking freshness before mutating configuration is the appropriate fix.

Should this CL be LGTMd?

Yes, LGTM.

[foundationdb-ci]

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

• Commit ID: aa55eeb
• Duration 0:22: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-macos-m1 on macOS 14.x

• Commit ID: aa55eeb
• Duration 0:34: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-clang-arm on Linux RHEL 9

• Commit ID: aa55eeb
• Duration 0:48: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 on macOS 14.x

• Commit ID: aa55eeb
• Duration 0:49:58
• 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 on Linux RHEL 9

• Commit ID: aa55eeb
• Duration 0:51:10
• 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: aa55eeb
• Duration 0:56:47
• 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: aa55eeb
• Duration 1:25:08
• 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)