feat(api): status folds surface the deployment's shared data-plane apply id - #1061
Draft
aparajon wants to merge 3 commits into
Draft
feat(api): status folds surface the deployment's shared data-plane apply id#1061aparajon wants to merge 3 commits into
aparajon wants to merge 3 commits into
Conversation
…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>
…l-id' into armand/deployment-apply-id-read
…l-id' into armand/deployment-apply-id-read
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
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.external_idcolumn 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.How it moves us toward the northstar
One data-plane apply per deployment; operations dispatch into it.
Opened by Claude (Fable 5).