Self-update: a pinned (UpdatePolicy=None) install rolls on every pod restart — the Startup pass runs under the configured DEFAULT policy before the persisted policy arrives #2797

What I saw on memex.meshweaver.cloud (2026-08-30)

Admin/UpdatePolicy has read policy: None all day (every version from v1896 @ 07:08Z through v2088 @ 15:19Z). Yet the install rolled twice — to be39fc607 (ci.6664) at ~11:54Z and to 41dd85a24 (ci.6739) at ~15:03Z (ready 15:57Z) — with /api/version proving both.

The node's own history explains it. Every pass whose lastCheckTrigger is Startup evaluates a candidate as if the policy were Continuous, and only the 1 h floor decides whether it rolls:

None → "Startup evaluates a candidate" → PolicyChange back to disabled, on every pod start.

Root cause

SelfUpdateHostedService.CreatePolicySource():

.SelectMany(_ => Observable
    .Defer(ReadPolicyStream)
    .RetryWhen(ResubscribeAfterRetryInterval("policy stream"))
    .StartWith(new UpdatePolicyContent { Policy = _options.DefaultPolicy }))   // Continuous
.DistinctUntilChanged(c => (c.Policy, c.RequireCiGreen));

The StartWith seeds the pipeline with the configured default (Continuous) before the persisted node's value arrives, and the Switch downstream runs a full RunOnce on that seed — ACR listing, candidate selection, and the Deployment PATCH — as the Startup pass. The persisted None arrives a second later as a "PolicyChange" and disables the updater — after the roll has already been issued.

So on a pinned (None) install, every pod (re)start that happens more than MinRollInterval after the last roll rolls the portal to the newest rollable tag. A restart for any reason (OOM, node drain, a probe failure, a Restart InstanceAction) becomes an unrequested upgrade. Pinning is not a pin. This is the exact evidence-confusion #2553 was about, with the opposite sign: an install the admin pinned advances, and the node says it never does.

Second finding, same log line

v1898's failed roll tried to PATCH memex-migration-deployment, which no longer exists — the migration is a run-once Job the chart runs on helm upgrade (#1788). The portal Deployment patch had already been issued by then, so the roll went ahead with no migration for the new image, which is exactly the state DbVersionGate exists to refuse. The updater's roll step still assumes the pre-#1788 topology.

Fix

• Do not seed the policy pipeline with the default. Read the persisted node first (EnsureExists already guarantees it exists — the seed was written with DefaultPolicy at creation, so nothing is lost) and run the first pass only on the value actually read. If the read must fall back, fall back to None (fail closed), never to Continuous.
• Make the roll step match the chart: no memex-migration-deployment patch; run the migration the way the chart does, or refuse to roll when it cannot.
• A guard test: a None node + a fresh service start must produce ZERO ACR calls and zero patches (SelfUpdateVerdict.UpdatesDisabled() as the Startup verdict, not a candidate evaluation).