Skip to content

test(tern): pin the one-data-plane-apply-per-deployment invariants - #1065

Draft
aparajon wants to merge 3 commits into
armand/deployment-apply-id-clifrom
armand/deployment-shared-apply-tests
Draft

test(tern): pin the one-data-plane-apply-per-deployment invariants#1065
aparajon wants to merge 3 commits into
armand/deployment-apply-id-clifrom
armand/deployment-shared-apply-tests

Conversation

@aparajon

@aparajon aparajon commented Aug 17, 2026

Copy link
Copy Markdown
Collaborator

Why this matters

The northstar's core invariant — one data-plane apply per deployment, with sibling operations attaching into it — is enforced across four PRs (dispatch keying, attach echo, fail-closed persistence, read model). This capstone pins the whole chain end to end so a regression in any layer fails a test that names the invariant, not a distant symptom.

What it does

  • A real in-process gRPC dispatch test drives both shard operations of one deployment: both requests carry the same deployment-keyed idempotency key, both operation rows record the deployment's one remote apply id, and the parent apply's external_id stays untouched.
  • A status-endpoint test proves the deployment-filtered fold surfaces the shared data-plane apply id on the folded row while keeping per-operation remote ids out of it.
  • The task-store mock now scopes GetByApplyOperationID to the requested operation the way the real store does, so multi-operation dispatch tests exercise genuine per-operation task sets.
  • Control-plane drive semantics for the shared apply — a completed sibling never terminalizes the parent, ordered finalizer gating, concurrent same-deployment shard drives — are already pinned by the operator multi-operation integration matrix; this PR adds the identity-correlation coverage on top rather than duplicating it.

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)    ✅ pinned here + existing matrix
4  read model exposes the deployment apply id   🔍 in review
5  CLI renders it as APPLY ID in deployment mode 🔍 in review
6  test matrix                                  ⬅ this PR

Opened by Claude (Fable 5).

aparajon and others added 3 commits August 17, 2026 12:35
Sibling shard operations of one deployment dispatched over the real gRPC
path carry the same deployment-keyed idempotency key, record the same
remote apply id on their operation rows, and never write the parent
apply's external_id. The deployment-filtered status endpoint folds those
operations into one row that surfaces the shared data-plane apply id
while keeping per-operation remote ids out of the fold. The task-store
mock now scopes GetByApplyOperationID to the requested operation the way
the real store does, so multi-operation dispatch tests exercise true
per-operation task sets.

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