40 lines
2.5 KiB
Markdown
40 lines
2.5 KiB
Markdown
## Context
|
|
|
|
The Platform already validates and dispatches `POST /api/v1/server-instances/{id}/deploy`; it accepts a draft or failed server only after its dedicated Run endpoint is registered. The server detail page exposes start, stop, and edit actions, but never calls that deployment API. As a result, a newly registered Run remains correctly idle and a failed server cannot be retried through the console.
|
|
|
|
## Goals / Non-Goals
|
|
|
|
**Goals:**
|
|
|
|
- Make the existing deployment transition available to an authorized operator from the server detail header.
|
|
- Use the current server config version and a unique idempotency key, then display ordinary operation feedback and refresh state.
|
|
- Make the action unavailable while installation is already active or the state is not deployable.
|
|
|
|
**Non-Goals:**
|
|
|
|
- Do not change the backend API, deployment plan, Run protocol, SCUM install sequence, or automatic-start behavior.
|
|
- Do not expose protected directories, commands, tokens, or remote connectivity details.
|
|
- Do not change the separate build target / dedicated Run identity boundary.
|
|
|
|
## Decisions
|
|
|
|
- Add the control beside existing lifecycle controls rather than auto-dispatching when a Run heartbeats. Registration proves connectivity only; automatic installation would make starting a downloaded executable perform a material remote write without a final operator action.
|
|
- Reuse `platformApiClient.deployServerInstance` rather than duplicating request logic. This preserves backend authorization, version fencing, idempotency, and job projection behavior.
|
|
- Reuse the existing operation store and `refresh()` callback so the detail page follows the same feedback pattern as start/stop and immediately shows the job state.
|
|
|
|
## Risks / Trade-offs
|
|
|
|
- [A stale page submits an outdated version] → The backend's `expectedConfigVersion` check rejects it; the UI refreshes after the error.
|
|
- [Users mistake registration for completed installation] → The action label explicitly distinguishes Deploy from Start, and the queued job result is shown through the standard task feedback.
|
|
- [A duplicate click creates duplicate work] → A fresh idempotency key is submitted and the backend enforces its lifecycle idempotency rules.
|
|
|
|
## Migration Plan
|
|
|
|
1. Deploy the frontend change with the existing Platform API.
|
|
2. Open a failed or draft server whose dedicated Run is online and select Deploy / Retry deploy.
|
|
3. Confirm the resulting install job is assigned to the dedicated endpoint. Rollback only removes the UI control; no data migration is required.
|
|
|
|
## Open Questions
|
|
|
|
None.
|