Skip to content

feat(api): status folds surface the deployment's shared data-plane apply id - #1061

Draft
aparajon wants to merge 3 commits into
armand/deployment-shared-external-idfrom
armand/deployment-apply-id-read
Draft

feat(api): status folds surface the deployment's shared data-plane apply id#1061
aparajon wants to merge 3 commits into
armand/deployment-shared-external-idfrom
armand/deployment-apply-id-read

Conversation

@aparajon

@aparajon aparajon commented Aug 17, 2026

Copy link
Copy Markdown
Collaborator

Why this matters

When an operator filters status by deployment, an apply that ran per shard folds its operations into one synthetic row — and that row carried no external id at all. The one identifier the northstar guarantees (one deployment → one data-plane apply) vanished exactly where the operator looks for it during an incident. The single-operation shapes already surfaced their id; the folded shape lost it.

What it does

  • The status fold resolves the deployment's shared data-plane apply id via a new strict resolver, storage.DeploymentExternalID, and carries it on the folded row. Per-operation external ids stay out of the summary — they belong to the per-shard detail views, so the folded row's external operation id is empty.
  • The strict resolver reads the external_id column only. The legacy engine-resume-context carrier is deliberately excluded on this read path: locally driven operations store engine-owned resume state there, not an apply id, and the fold covers local applies too. DeploymentRemoteApplyID (the write-path resolver, legacy carrier honored) and the strict variant now share one core.
  • Divergent ids across one deployment's operations are never guessed at: the response omits the external id and the divergence is logged server-side with the apply's triage identifiers.

How it moves us toward the northstar

One data-plane apply per deployment; operations dispatch into it.

0  per-shard reconcile                          ✅ shipped
pre vschema-only deployment-scoped shape        ✅ shipped
pre op-lease drives settle projection-safely    ✅ shipped
1  dispatch granularity
   ├─ data-plane sibling attach                 ✅ merged
   └─ deployment-keyed idempotency + echo       ✅ merged
2  correlation persistence                      🔍 in review
3  op-scoped data-plane drive (shared apply)    verified in step 6
4  read model exposes the deployment apply id   ⬅ this PR
5  CLI renders it as APPLY ID in deployment mode
6  test matrix

Opened by Claude (Fable 5).

aparajon and others added 3 commits August 17, 2026 12:15
…ply id

A deployment applied per shard folds its operations into one status row, but
the fold never carried an external id, so operators lost the data-plane apply
handle exactly where the northstar promises one: one deployment, one
data-plane apply. The fold now resolves the deployment's shared apply id with
a strict external_id-only resolver (DeploymentExternalID) — the legacy engine
resume context carrier is excluded because on locally driven operations it
holds engine-owned resume state, not an apply id. Divergent ids across one
deployment's operations are omitted from the response and logged server-side
rather than picking one.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant