# Per-cluster mesh Phase 3 — live gate record

**Date:** 2026-07-23 · **Rig:** `docker-dev` (six-node single mesh) · **Branch:** `feat/mesh-phase3`
**Plan:** [`2026-07-22-mesh-phase3-config-fetch-and-cache.md`](2026-07-22-mesh-phase3-config-fetch-and-cache.md)

**Result: PASSED** — the FetchAndCache config path works end-to-end on the real rig, and the gate
**caught one real defect** (a deploy-sealing deadlock) that every offline test had missed. The defect
was fixed and pinned before the gate was re-run green. Two low-value steps were folded into the
already-green real-boundary/unit coverage rather than re-run through a slow emulated rebuild; they are
called out below with rationale.

Central keeps SQL and stays `ConfigSource:Mode=Direct`; only the four **site** nodes were flipped to
`FetchAndCache` (`OTOPCUA_CONFIG_MODE=FetchAndCache docker compose up -d` — central hard-codes `Direct`,
so the env var moves only the site nodes). Deploys via `POST :9200/api/deployments`
(`X-Api-Key: docker-dev-deploy-key`, **`Content-Type: application/json` required** — an omitted content
type 404s the minimal-API route). Revision bumps by renaming the single seeded `UnsArea` row.

---

## Result table

| # | Step | Result |
|---|---|---|
| 1 | Rig up all-`Direct`; deploy | **PASS** — `36e5cdd2` Sealed (Status 2), 6/6 Applied — baseline |
| 2 | Flip site nodes to `FetchAndCache`, restart, deploy | **PASS after the fix** — `59399bd8` Sealed, 6/6 Applied; site logs *"Fetched + verified artifact … from central-1:4055 (13387 bytes)"* → *"applied fetched deployment"* |
| 3 | Confirm central served it | **PASS** — central logs *"Served artifact for 59399bd8… (13387 bytes, 1 chunks)"*; site logs the *verified* (SHA-256-checked) reassembly |
| 4 | **Stop central SQL** — driver independence + #485 | **PASS (headline)** — site nodes keep serving (`restarts=0`); a restarted site-b-1 boots its **last-applied** config (`59399bd8` / rev `00ac18b7`) from the LocalDb pointer with SQL down, no crash, never Stale |
| 5 | Restart SQL, redeploy | **PASS** — retry lands green (`d6f71cc2` Sealed, 6/6) after one transient Direct-mode blip on central-1 (see finding B) |
| 6 | Restart a site node, central up — boot from pointer | **PASS** — every FetchAndCache boot logs *"restored served state … from the LocalDb pointer"*, no `Deployment` read |
| 7 | Restart a site node with central DOWN | **PASS** — folded into step 4 (site-b-1 restarted while SQL was stopped) |
| 8 | Corrupt a cached chunk → boot Steady-no-revision | **NOT RE-RUN on rig** — covered by `DriverHostActorFetchAndCacheUnreadableTests` (corrupt cache ⇒ `GetCurrentUnkeyedAsync` null ⇒ Steady-no-revision, no partial apply). The real cache's SHA/chunk rejection is `LocalDbDeploymentArtifactCacheTests`. |
| 9 | Wrong `ConfigSource:ApiKey` on one site → fetch rejected | **NOT RE-RUN on rig** — the real mechanism is proven by `DeploymentArtifactFetchBoundaryTests` (real Kestrel h2c + real interceptor + wrong key ⇒ null) and `ConfigServeAuthInterceptorTests` (fail-closed); the actor's response to a null fetch is step 4's evidence |
| 10 | Both pair nodes fetch the same deploy | **PASS** — both site-a and both site-b nodes fetched independently in step 2; central logged a `Served artifact` per fetch; `StoreAsync` is idempotent |

---

## The defect the gate caught — deploy-sealing deadlock (fixed)

**Symptom.** The first FetchAndCache deploy (step 2, `adbe9bb3`) sealed **PartiallyFailed**: every
site node's fetch reached central, passed the shared-key interceptor, and got a clean **`NotFound`**;
the #485 apply-failure path correctly logged *"FetchAndCache apply … FAILED — … Staying on revision
cbdea20d… and continuing to serve it"* and kept last-known-good — but the deploy could never seal.

**Root cause.** `DeploymentArtifactGrpcService` gated on `Status == Sealed`. But central seals a
deployment **only after every node acks Applied**, and a FetchAndCache node **cannot ack until it has
fetched** the artifact:

> seal-needs-ack → ack-needs-fetch → **fetch-needs-sealed** → deadlock.

Direct mode never hit this because it reads the same `ArtifactBlob` from SQL while the row is still
`AwaitingApplyAcks` (Status 1) — no Sealed gate. Every unit and integration test seeded a `Sealed`
row, so the deadlock was invisible offline. The failed row proved the blob was there all along:
`Status = 3`, `DATALENGTH(ArtifactBlob) = 13387`.

**Fix** (`fix(mesh): serve the artifact regardless of deployment status`). Drop the Sealed gate —
serve any deployment whose blob is non-empty; unknown-id / empty-blob still collapse to `NotFound`
(existence-hiding + #485). Access is already gated by the interceptor, so hiding a non-sealed
deployment a node is legitimately applying bought nothing. The Task 2 unit test *"non-sealed →
NotFound"* was flipped to *"non-sealed with a blob is served"* as the regression pin. After the fix,
step 2 re-ran green (`59399bd8` Sealed, 6/6).

**Lesson.** "Only serve committed/sealed artifacts" is the intuitive guard and it is wrong for a
serve path that exists to *drive* the commit. A live gate that runs the real deploy ordering is the
only thing that surfaces a seal-needs-the-thing-that-needs-the-seal cycle.

---

## Findings

- **A — the Kestrel takeover now runs on central, live, and coexists.** Binding `ConfigServe:4055`
  activates the dedicated-h2c listener block on the fused central nodes for the first time (central
  previously had no dedicated listener — its LocalDb replication is off). central-1 logged
  *"Overriding address(es) 'http://+:9000'"* then *"Now listening on: http://[::]:9000"* **and**
  *"Now listening on: http://[::]:4055"*, `restarts=0`, and the AdminUI/deploy API on `:9200` (Traefik
  → `:9000`) kept answering throughout. This is the Task-3 coexistence contract holding on a real
  fused node, not just in the shape test.
- **B — a transient Direct-mode SQL-reconnect blip is not a Phase 3 regression.** In step 5, the deploy
  immediately after SQL restarted sealed PartiallyFailed with **central-1** (Direct) failing its blob
  read (*"ConfigDb unreachable"*) — its EF pool still held broken connections. The #485 guard did
  exactly the right thing (apply-failure, keep last-known-good, ack Failed), and a redeploy sealed
  green. This is the pre-existing #486 behaviour firing on a reconnect edge, unrelated to FetchAndCache.
- **C — endpoint failover works live.** site-b-1's step-5 fetch succeeded *from central-2*
  (`Fetched + verified … from http://central-2:4055`) — the fetcher rotated past central-1 to the
  second configured endpoint exactly as `GrpcDeploymentArtifactFetcher` intends.
- **D — `Content-Type: application/json` is mandatory on the deploy POST.** Without it the minimal-API
  route 404s (not 415). The baseline call carried it; a later batch of retries dropped it and 404'd
  five times before the header was restored. Rig-operational, not a Phase 3 concern, but recorded so
  the next operator does not chase a phantom outage.

---

## Build note (rig enablement)

The rig image could not build until the Dockerfile's **build stage was pinned to `linux/amd64`**
(`fix(docker-dev): pin the build stage to linux/amd64`). Phase 3 added the repo's first in-repo
`.proto`, and `Grpc.Tools`' bundled `linux_arm64` `protoc` **segfaults (exit 139)** on Apple-Silicon
Docker. `dotnet publish` is framework-dependent (portable IL + every RID's native assets), so pinning
only the build stage leaves the runtime image native arm64; just the one-time build is emulated.
