30 lines
1.4 KiB
Markdown
30 lines
1.4 KiB
Markdown
# SpawnWorker failed because the active Runtime CLI rejected its launch protocol
|
|
|
|
Date: 2026-07-30
|
|
|
|
## Context
|
|
|
|
While implementing Ticket `00001KYS7YMN5`, the parent Worker delegated two read-only code-mapping tasks through `SpawnWorker`.
|
|
|
|
Both launches failed before a child socket appeared. The spawned process reported:
|
|
|
|
```text
|
|
yoi-runtime: unexpected positional argument `worker`
|
|
|
|
Usage: yoi-runtime [OPTIONS]
|
|
```
|
|
|
|
The active `yoi-runtime` binary accepts only its HTTP Runtime server options and auth subcommands, while the Worker-management layer attempted to start a child through a legacy `worker` positional command.
|
|
|
|
## Impact
|
|
|
|
- Delegated read-only investigation was unavailable.
|
|
- The parent Worker had to perform the code mapping directly.
|
|
- This is protocol/version drift between the Worker-management launch path and the active Runtime binary, not a failure in the delegated task or scope.
|
|
|
|
## Suggested improvement
|
|
|
|
Make the child-launch protocol explicit and versioned rather than invoking a user-facing Runtime CLI subcommand implicitly. At minimum, Runtime registration/health should advertise the supported spawn protocol, and `SpawnWorker` should reject an incompatible Runtime with a bounded compatibility diagnostic before attempting to create a child socket.
|
|
|
|
The active backend/runtime should also be rebuilt and restarted together after CLI/launch-protocol changes so long-running Worker-management processes do not retain an obsolete invocation contract.
|