Skip to content

feat(github): name the operator on a control request the data plane records - #1020

Draft
aparajon wants to merge 1 commit into
armand/remote-control-rejection-mirrorfrom
armand/control-request-caller
Draft

feat(github): name the operator on a control request the data plane records#1020
aparajon wants to merge 1 commit into
armand/remote-control-rejection-mirrorfrom
armand/control-request-caller

Conversation

@aparajon

Copy link
Copy Markdown
Collaborator

Stacked on #967.

Why this matters

A durable control request names who asked for the operation, and that name is what the apply log and the "command not applied" notice show an operator. But the control RPCs carried no caller, so whenever the plane that recorded the request was not the plane the operator talked to, the row named the RPC path instead of the person. For volume that was true even in a single deployment, because the request is only ever recorded by the serving plane.

BEFORE                                  AFTER
──────────────────────────────────      ──────────────────────────────────
operator   schemabot cutover            operator   schemabot cutover
accepting  resolves cli:armand          accepting  resolves cli:armand
   ↓ RPC carries apply id + env            ↓ RPC also carries the caller
serving    records "tern-grpc"          serving    records "cli:armand"
PR         rejected by tern-grpc        PR         rejected by cli:armand

What it does

  • caller on the five control requests that record a durable row: cutover, stop, cancel, start, volume. The accepting plane sets the identity it already resolved for the apply log.
  • A drive that forwards an operator's queued cutover or start passes on the requester stored with that request, so carrying out a command keeps the name attached to it rather than re-recording the operation as its own.
  • A request arriving without a caller — an internal resume, or a plane that predates the field — still names the forwarding path. Inventing an operator would be worse than saying which path it came from, and the mirror in feat(observability): mirror remote control-request rejections back to the accepting plane #967 relies on that name being distinguishable from a real one so it never displaces a known operator.
  • volume resolved the caller for its log line only; it now resolves once and uses it for both the log and the request, matching every other control path.

Revert and skip-revert are unchanged: their durable rows are recorded by the accepting plane, which already has the caller.

🤖 Generated with Claude Code

…ecords

The control RPCs carried no operator identity, so every durable control request
recorded by the plane serving the command named the forwarding path instead of
the person who issued it. That name is what the apply log and the PR notice for
an accepted-but-unapplied command show.

The five control RPCs that record a durable request now carry the caller the
accepting plane resolved, and a drive forwarding an operator's queued cutover or
start passes on the requester already stored with it. A request that arrives
without one still names the forwarding path rather than inventing a person.

Co-Authored-By: Claude Opus 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