30 lines
2.5 KiB
Markdown
30 lines
2.5 KiB
Markdown
## Context
|
|
|
|
Platform currently stores `serverInstances.state` as both desired state and observed runtime state. `CompleteRunJob` projects successful lifecycle jobs directly into that field, so a previous `process.start` success can leave a server as `running` even after the actual Run-managed process is gone. A manually started generated Run can register and heartbeat, but platform will not dispatch another start job because it trusts the stale stored state.
|
|
|
|
Run already has the safer primitive: it owns the generated package startup path and can report redacted `processState` facts from inside the generated Run workspace. This change uses Run reports as the observed runtime source and avoids Platform registration-time probes.
|
|
|
|
## Goals / Non-Goals
|
|
|
|
**Goals:**
|
|
- Stop generated Run startup from relying on a platform-dispatched registration-time `process.status` job.
|
|
- Project server state from Run `processState` for status/start/stop lifecycle results.
|
|
- Preserve Platform ownership of authorization, leases, and audit for explicit operator requests while treating generated Run bootstrap as Run-owned.
|
|
|
|
**Non-Goals:**
|
|
- Add a new live telemetry protocol or raw process list to heartbeat.
|
|
- Hardcode SCUM-specific executable names, Steam app IDs, paths, ports, or health checks in platform or Run.
|
|
- Change plugin create wizard requirements or distribution-build ownership.
|
|
|
|
## Decisions
|
|
|
|
- Do not queue status reconciliation on generated Run registration. Registration confirms identity and session only; Run-owned lifecycle/status reports correct stale Platform projections.
|
|
- Keep explicit `process.status` result projection for operator-requested or Run-reported status flows that are not registration bootstrap side effects.
|
|
- Project `process.status` into lifecycle state with conservative mapping: `running` => `running`, `stopped/not-started` => `stopped`, unexpected `exited` => `failed`, operator-stopped `exited` => `stopped`.
|
|
|
|
## Risks / Trade-offs
|
|
|
|
- A plugin start wrapper can be `running` while still installing dependencies. This change does not solve game readiness; it only prevents platform from preserving stale process state when Run reports no managed process.
|
|
- Status reconciliation is asynchronous. A manual Run may briefly appear with stale state until it claims and completes the status job.
|
|
- If a server process was started outside the active generated Run workspace, the registering Run will report `not-started` and platform will mark stopped. That is intentional: unmanaged external processes are not authoritative for platform lifecycle.
|