The same-major swap and in-place upgrade tests expect the postgresql.conf shape the managed-conf migration writes

[erikdarlingdata]

What was failing

The 2026-09-27 nightly run's gated PostgreSQL leg failed
DarlingStoreUpgradeTests.RuntimeAdvance_SameMajorStoreWithRealData_SwapsWithoutPgUpgradeAndKeepsEverything_Gated
(both stamped: True and stamped: False) at DarlingStoreUpgradeTests.cs:3118:

Assert.Equal(1, CountOccurrences(conf, DarlingManagedPostgres.ConfMarker));
Expected: 1
Actual:   0

The same shape of assertion, on the same read of postgresql.conf, also exists in
UpgradeInPlace_OldMajorStoreWithRealData_UpgradesAndKeepsEverything_Gated at the old line 2903 (this run's
own failure there was a later, unrelated socket error after that line — the marker assertion itself had
already passed there, which is the tell that something else was different about the same-major path).

Classification: stale test (S), not a product bug

PR #4336 ("Move the managed store's settings into one included file, darling-managed.conf") changed the
store's own conf layout on purpose: from that PR on, a data directory that gets a service-owned start
migrates its postgresql.conf from the old v1-v15 appended-block shape into one include 'darling-managed.conf' line, with the settings (and their markers) rendered fresh into that included file
instead. ManagedConfMigrationState.Classify's own doc comment states the rule: only a Legacy conf (a
v-marker still present, or the include missing) may run the legacy appenders; a migrated conf never gets
them back. Both gated tests here run the product's real bootstrap through a full start, which is exactly the
one start that performs this migration — so postgresql.conf correctly ends up with the include and zero
occurrences of ConfMarker/ConfMarkerV6/ConfMarkerV7, not one. ManagedConfUpgradePathTests.cs:261-262
already asserts this same correct post-migration shape (ManagedConfFile.HasManagedInclude(conf) true) for
a real major upgrade — these two DarlingStoreUpgradeTests.cs pins were just never updated to match when
#4336 landed on top of them, and #4446 (which touched a neighboring preload-line assertion in the same
tests, closing the 2026-09-26 nightly's finding) didn't reach this line either.

The fix

Changed both assertions from Assert.Equal(1, CountOccurrences(...)) to Assert.Equal(0, CountOccurrences(...)), and added Assert.True(ManagedConfFile.HasManagedInclude(conf), ...) right before
them, matching the pattern ManagedConfUpgradePathTests.cs already uses for the same migrated shape. Both
sites got a comment naming #4336 as the reason the count is 0. No product code changed.

I scanned the rest of DarlingStoreUpgradeTests.cs (git grep -n "CountOccurrences(conf, DarlingManagedPostgres.ConfMarker") and found only these two sites — no further
stale assertions of this shape remain in this file.

The in-place upgrade test had also checked shared_preload_libraries in postgresql.conf, where it no longer lives. bf74a5e94 replaces that check with ManagedPreloadAssert.FileLevel_HasOneManagedPreloadLine_WithBothLibraries, the same file-level check the same-major swap test makes after #4446. So the preload line is still checked, now where #4336 puts it.

Sibling gated tests checked

• ManagedConfUpgradePathTests.cs (UpgradeInPlace_OperatorLineBelowInclude_CarriedAndApplied_NoManagedKeyDuplicated_Gated
  and its neighbors) already assert the correct post-Move the managed store's settings into one included file, darling-managed.conf (#4215) #4336 shape (HasManagedInclude true, no v-marker) —
  consistent with this fix, no changes needed there.
• DarlingManagedPostgresTests.cs has several CountOccurrences(conf, DarlingManagedPostgres.ConfMarkerV8)
  assertions expecting 1 (or the deliberately-broken 3), but those exercise EnsureConfAppended directly on
  a still-Legacy conf, never through a migration — a different scenario, not stale.

When it last passed / what changed it

#4336 (6dbb22a50, "Move the managed store's settings into one included file, darling-managed.conf") is
on dev and is an ancestor of 3f3f7cb95, the exact sha the 2026-09-27 nightly tested (git merge-base --is-ancestor 6dbb22a50 3f3f7cb95 confirms it) — so these two gated tests have been asserting the pre-#4336 shape against
post-#4336 product code since that commit landed, and could only have been green before it. The last green nightly run was not looked up by number;
the code-level evidence (the commit that changed the behavior, and the matching-shape assertion already
correct in ManagedConfUpgradePathTests.cs) is conclusive on its own for classifying this as stale (S) rather
than a product bug, and gives the exact commit to cite. My branch is cut from origin/dev at 3f3f7cb95,
the same sha the nightly ran, so this fix applies cleanly with no missing prerequisite commit.

Gated tests that must pass

These pass only on a test-only nightly.yml run (publish=false); PR CI doesn't run them. The in-place upgrade test also fails earlier, on a separate cause fixed in its own PR, so it needs both changes for a pass.

• Darling.Tests.DarlingStoreUpgradeTests.RuntimeAdvance_SameMajorStoreWithRealData_SwapsWithoutPgUpgradeAndKeepsEverything_Gated(stamped: True)
• Darling.Tests.DarlingStoreUpgradeTests.RuntimeAdvance_SameMajorStoreWithRealData_SwapsWithoutPgUpgradeAndKeepsEverything_Gated(stamped: False)
• Darling.Tests.DarlingStoreUpgradeTests.UpgradeInPlace_OldMajorStoreWithRealData_UpgradesAndKeepsEverything_Gated

These are Windows-only, gated behind DARLING_TEST_PGRUNTIME_*; they cannot run on macOS. The build is
clean (0 errors, 0 warnings) for Darling.Tests.csproj with EnableWindowsTargeting=true.

CHANGELOG entry

None: a test-only change. It updates gated test assertions to the postgresql.conf shape the store already produces after its managed-conf migration, and no product behavior changes.