Skip to content

✨ feat(runtime): orchestrate typed Stop with owned child termination - #777

Merged
seakee merged 2 commits into
v2from
feat/v2-runtime-stop-mutation
Sep 15, 2026
Merged

seakee merged 2 commits into
v2from
feat/v2-runtime-stop-mutation

Conversation

@seakee

@seakee seakee commented Sep 15, 2026

Copy link
Copy Markdown
Owner

Summary

Adds authenticated typed Stop submission to Runtime Protocol v1. Stop records durable accepted/running evidence before terminating only the exact child owned by the current Supervisor, and reports success only after that child is confirmed reaped.

Start and Stop now share one lifecycle executor, process manager, operation journal, mutation gate, shutdown admission fence, and exactly-once journal close.

Scope

  • Frontend panel
  • Manager Server
  • CPA panel mode
  • Full Docker mode
  • Native packages / release
  • Docs / Wiki
  • CI / build / tooling

Changes

  • Add POST /v1/runtime/operations/stop with the strict common mutation envelope, fixed stop type, SHA256("runtime.stop/v1:{}") fingerprint, and deterministic start, stop capabilities.
  • Reserve an opaque exact-child target before durable intent, use hard termination without caller PID/signal authority, wait for the existing cmd.Wait() path to confirm reap, and fail closed on unknown ownership.
  • Serialize Start and Stop through one shutdown-aware executor so replay, terminal persistence failure, concurrent Stop IDs, and replacement-child races cannot repeat or redirect termination.
  • Amend ADR-0001 and add focused protocol, lifecycle, real-process, failure-window, cancellation, replay, ABA, shutdown, and environment-regression coverage.

Historical asset review: inspected the directly relevant child-handle termination and process tests on feat/integrated-cpa-runtime. Reused only the handle-plus-Wait mechanics and failure/race scenarios as design input; no historical code was copied. Manager-owned supervision, persistent PID authority, caller-selected termination, graceful escalation, automatic restart, cancellation-driven kill, storage/config ownership, and Docker orchestration remain rejected.

User Impact

A configured v2 Runtime Supervisor now accepts typed Stop operations for its currently owned CPA child. Read-only mode remains unchanged and advertises no lifecycle capabilities.

Compatibility / Runtime Notes

  • CPA panel mode: N/A.
  • Manager Server mode: No RuntimeClient mutation or reconcile wiring is added.
  • Full Docker / native packages: The standalone Supervisor protocol and portable binary support Stop; deployment wiring remains out of scope.

RuntimeGeneration remains stable across Start/Stop, and Stop does not add readiness or CPAObservedVersion behavior. Runtime 07 child environment filtering and ordinary proxy/certificate/locale/XDG inheritance remain unchanged.

Data / Security Notes

The existing Supervisor-private journal schema is unchanged. Stop persists only operation identity/state and stable failure code; no PID, signal, process target, secret, or secret-derived fingerprint is stored or accepted from HTTP callers.

Risk / Rollback

Risk level: Medium

The main risk is process lifecycle concurrency. Exact-handle reservation, shared serialization, confirmed Wait/reap, cross-generation replay, shutdown admission fencing, real-child tests, and full race tests cover that boundary. Roll back by reverting this commit; no schema migration or product-data change is involved.

Verification

  • Type check
  • Lint
  • Tests
  • Build
  • Manual UI check
  • Docs/link check
  • Not applicable, docs-only

Commands / evidence:

cd apps/runtime-supervisor
GOWORK=off GOFLAGS=-mod=readonly go test -count=1 ./internal/cpaprocess ./internal/lifecycle ./internal/protocol ./cmd/cpamp-runtime-supervisor
GOWORK=off GOFLAGS=-mod=readonly go test -count=1 ./...
GOWORK=off GOFLAGS=-mod=readonly go test -race -count=1 ./...
GOWORK=off GOFLAGS=-mod=readonly go vet ./...
GOWORK=off CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -trimpath -o /private/tmp/cpamp-runtime08-build.pv8m0i/supervisor-linux-amd64 ./cmd/cpamp-runtime-supervisor
GOWORK=off CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -trimpath -o /private/tmp/cpamp-runtime08-build.pv8m0i/supervisor-linux-arm64 ./cmd/cpamp-runtime-supervisor
GOWORK=off CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build -trimpath -o /private/tmp/cpamp-runtime08-build.pv8m0i/supervisor-windows-amd64.exe ./cmd/cpamp-runtime-supervisor
cd ../..
GOWORK=off go test ./bin/ci/runtime-boundary/main.go ./bin/ci/runtime-boundary/main_test.go
GOWORK=off go run ./bin/ci/runtime-boundary/main.go
git diff --check

All commands passed. Portability outputs were verified as Linux x86-64 ELF, Linux ARM64 ELF, and Windows x86-64 PE32+ executables.

Screenshots / Recordings

N/A — Runtime Supervisor protocol/process change with no UI.

Docs

  • README / README_CN updated for user-visible capabilities
  • Matching docs manual and navigation updated
  • Demo fixtures, screenshots, and deep links reviewed
  • Release notes needed
  • Not needed — explanation included below

Docs decision: ADR-0001 is amended with the long-term typed Stop contract. End-user docs are deferred because Manager, Docker/native deployment, UI, and Public API wiring are outside this slice.

Related

N/A — CPAMP 2.0 Runtime Foundation, Runtime 08.

Add authenticated typed Stop with durable intent, cross-generation replay, and strict request fencing.

Reserve and terminate only the exact Manager-owned child, wait for confirmed reap, and serialize Start/Stop through one shutdown-aware lifecycle executor.
Close lifecycle admission before HTTP shutdown waits for active handlers, then let the existing shared gate drain accepted execution before closing the journal.

Cover the production server path with an accepted Start, a queued Start, durable journal evidence, and exactly-once close assertions.
@seakee
seakee merged commit c46f292 into v2 Sep 15, 2026
11 checks passed
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