snapshotConfig_roundTrips

SnapshotMeta has three fields and the suite asserted two — and the third is the one the suite's own KDoc already named as the failure. snapshotAtZeroBaseline_roundTrips argues that an adapter with nullable-with-default metadata columns "loses that config and comes back under the wrong cluster configuration", and then does not assert it: every snapshot above is built SnapshotMeta(index, term), leaving SnapshotMeta.config at its null default, which is precisely what a dropped column decodes to.

The value is load-bearing and it is the only carrier of its fact. RaftEngine seeds state.snapshotConfig from it on restore, and compaction discards the config log entries that produced it — so a node that compacted past a membership change has nothing else to recover the voter set from. A dropped config there is not a lost optimisation; it is a node rejoining under a cluster membership that no longer exists.

Joint (old != null), with a learner in the new half — both are knob settings that would switch detection off if taken the comfortable way. A simple payload leaves old at null, so an adapter persisting only new would round-trip it perfectly; a new with no learners leaves ClusterConfig.learners at its emptySet() default, so an adapter persisting only voters would too. Both halves and both collections are non-default here, so neither shortcut has anywhere to hide.

What this cannot detect: a config that is stored but fabricated on the absent path — an adapter decoding a missing config to a non-null empty ClusterConfig. anUnwrittenMediumReopensEmpty is the only property that opens that door, and it opens it for the snapshot as a whole rather than for this field.