Skip to content

feat(app): isolate explicit client launch from owner execution - #703

Open
wolfy-j wants to merge 3 commits into
mainfrom
feat/application-launch-admission
Open

feat(app): isolate explicit client launch from owner execution#703
wolfy-j wants to merge 3 commits into
mainfrom
feat/application-launch-admission

Conversation

@wolfy-j

@wolfy-j wolfy-j commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

Purpose

Let a Builder-produced executable select an application-specific client or owner invocation without changing ordinary Wippy runtime semantics.

Design

  • All implementation and contracts live in cmd/app, following chore: keep native application code under cmd #727. No api/application, public statelock package, Lua API, or boot-component discovery is added.
  • Options.Launch is an explicit native callback. It can run a client directly or call the one-shot, scoped owner runner. The application owns discovery, authentication, admission and attachment errors.
  • The owner runner alone acquires application-state ownership, prepares native owner resources, opens deployment/history, executes the existing runtime command, and cleans up before unlocking.
  • Actual contention returns app.ErrBusy; filesystem errors are not contention. No automatic attachment, retry, or owner fallback occurs.
  • Recovery, update and runtime tooling bypass the callback. Explicit state selection and registry-history ownership remain fixed.
  • An escaped/repeated owner runner is rejected. Returning while it is active cancels and joins it and reports a lifecycle error.

#726's embedded-baseline selection is a separate application option, not a launch result. Builder and Bee need corresponding explicit wiring; the former implicit PrepareLaunch component integration is intentionally removed. Do not merge until those integration checks are complete.

Validation

  • go test -race ./cmd/app -count=10 passes.
  • Pinned golangci-lint on ./cmd/app/...: zero issues.
  • Windows amd64 non-CGO application test binary cross-compiles (not executed on Windows).
  • Tests cover client-only state isolation, busy-owner routing without store access, lock I/O errors, preparation/seed failure cleanup under ownership, reserved operation bypass, expired owner credentials, fixed registry history, and runner lifetime enforcement.
  • No changes outside cmd/app; no docs or README files added to the repository.

@wolfy-j
wolfy-j force-pushed the feat/application-launch-admission branch from 0851129 to 8016b46 Compare September 10, 2026 23:37
@wolfy-j wolfy-j changed the title Add native application owner preparation and client attachment hooks feat(app): isolate explicit client launch from owner execution Sep 10, 2026
@wolfy-j

wolfy-j commented Sep 11, 2026

Copy link
Copy Markdown
Contributor Author

Polished cmd/app in d6937ee: validate all data-environment bindings before applying any, reject NUL paths, preserve explicit empty overrides, and check cancellation before creating owner state. Added regression tests; 10 race repetitions and scoped lint pass. Merged current main to include the approved shutdown/WebSocket fixture corrections. No exported API added. Bee integration remains a merge gate: the inspected native launcher still uses api/application.PrepareLaunch/LaunchPlan and must move to the explicit cmd/app callback. No compatibility claim for that old native wiring.

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.

2 participants