Problem

When a disaggregated-storage follower picks up a checkpoint for a table it already has, it merges only the checkpoint field from the shared metadata into its local metadata. It never checks that the rest of the config still agrees. Fields such as key_format, value_format, collator, and the btree id are ignored.

If any of these diverge for the same table, the follower keeps its stale local config while adopting the new shared checkpoint address. It then reads the on-disk pages under the wrong schema or the wrong btree ID, so value decoding and history-store lookups resolve against the wrong tree. The failure is silent data corruption, not a clean error. A mismatched id is the worst case, because it points reads directly at another tree's blocks and history-store entries.

This check is independent of node role and lifecycle. It fires only when an entry exists in both the local and shared metadata, where these fields must always match. It is therefore safe to keep on in production, unlike strict_checkpoint_metadata, which must be toggled around startup and step-down.

Fix

On pickup, compare the immutable config fields for every table present in both the local and shared metadata, and fail loudly on any mismatch. Compare only fields that must stay stable across a pickup - key_format, value_format, collator, id, and block and allocation parameters - and skip fields that change each checkpoint, such as checkpoint, checkpoint_lsn, and write_gen. Cover all four URI schemes, not just file:.

Test

Add a follower-pickup test where the shared metadata for an existing table carries a different id, and separately a different key_format, than the follower holds locally. Assert the pickup fails instead of corrupting reads.