43 lines
3.1 KiB
Markdown
43 lines
3.1 KiB
Markdown
## Context
|
|
|
|
Platform dispatches `distribution.build` through a trusted Run endpoint. A newer server lifecycle already distinguishes `DeploymentTargetID` from a dedicated `RunEndpointID`, but legacy instances can still have only `RunEndpointID`. A generated Run for such an instance was built with the shared endpoint identity and its component key, so starting it remotely replaced the local build worker registration.
|
|
|
|
## Goals / Non-Goals
|
|
|
|
**Goals:**
|
|
|
|
- Preserve a local trusted Run worker as the only component that compiles generated Windows Run binaries.
|
|
- Give generated Run packages a deterministic server-scoped identity.
|
|
- Make legacy generation self-heal the unsafe endpoint binding before a build is queued.
|
|
- Prevent generated Run packages from advertising build-only worker capabilities.
|
|
|
|
**Non-Goals:**
|
|
|
|
- Do not move compilation into the browser, expose source trees to plugins, or require Go/Git on the game host.
|
|
- Do not alter deployment commands, game dependencies, or remote server files.
|
|
|
|
## Decisions
|
|
|
|
1. When a failed or draft legacy instance requests a Run distribution, Platform atomically promotes its existing endpoint to `DeploymentTargetID` and reserves `server-run-<server-id>` as the generated Run endpoint. Generation is an explicit operator action and is the safe migration boundary; it avoids changing active legacy instances merely because Platform starts.
|
|
2. Component-authenticated Run hello must match the instance's dedicated Run endpoint. A component token cannot register over a shared build endpoint.
|
|
3. Run capability reporting is role-aware. A component-authenticated generated Run keeps lifecycle/file/dependency capabilities but never reports distribution build or Run self-update capabilities. A generic worker remains build-capable.
|
|
4. Source-preparation failures return a bounded category that distinguishes unavailable source, invalid source layout, and unsafe source content without exposing host paths.
|
|
|
|
## Risks / Trade-offs
|
|
|
|
- [A failed legacy instance needs a fresh package] → Generation performs the migration before queueing and produces a package with the new identity.
|
|
- [A stale remotely deployed package continues to reconnect] → Platform rejects it after migration because its endpoint ID no longer matches the component's dedicated identity.
|
|
- [Role-aware capabilities change scheduling] → Only build-only capabilities are removed from component packages; normal server lifecycle capability reporting is preserved.
|
|
|
|
## Migration Plan
|
|
|
|
1. Deploy Platform and Run changes.
|
|
2. Start the local generic build worker with `run-local-debug` and its approved source snapshot.
|
|
3. Generate Run for the failed legacy server; Platform promotes `run-local-debug` to its deployment target and embeds `server-run-<id>` in the new Windows package.
|
|
4. Replace the old remote executable with the generated package; its stale shared-ID registration is rejected.
|
|
5. Roll back by retaining the old package and restoring the legacy binding only through an explicit recovery operation; Platform never silently maps a component token onto a shared builder endpoint.
|
|
|
|
## Open Questions
|
|
|
|
- None.
|