You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Client-side wiring for the v1.58 gateway endpoint
POST /apply/v1/releases/:id/promote (run402-private commit b25ae87b,
deploy fix a47961ac). Operator pointer-swap recovery primitive — re-point
internal.projects.live_release_id at an existing release without
re-running the apply pipeline.
SDK:
- deploy.types.ts: PromoteOptions, PromoteResult, PromoteDiff exported.
Mirror ApplyOptions for the parts that apply (allowWarnings,
allowWarningCodes); skip onEvent / idempotencyKey / maxRetries
(promote is single-shot).
- deploy.ts: Deploy.promote(project, releaseId, opts) method. POSTs to
/apply/v1/releases/:id/promote with body { project, allow_warning_codes }.
Local validation for releaseId shape (must start with rel_) + project
id non-empty. allowWarnings: true expands to the known
blocking-warning list (currently [MIGRATIONS_NOT_REVERSIBLE]) — no
server-side wildcard accept.
- scoped.ts: ScopedApplyHero.promote attached to the hero. Direct-SDK
consumers call r.project(id).apply.promote(releaseId, opts).
CLI:
- cli/lib/deploy-v2.mjs: promoteCmd + parsePromoteArgs + PROMOTE_HELP.
Positional <release-id> (must be rel_*), --project (falls back to
active project), --allow-warning (repeatable), --allow-warnings
(ack all blocking), --quiet. Calls _applyEngine.promote directly
(same pattern as the rest of the CLI — getSdk() returns the
unwrapped Run402 instance whose project() is async, so the hero
path would need an extra await for marginal clarity).
- cli/lib/deploy.mjs: 'promote' added to the deploy-subcommand allowlist.
- cli/llms-cli.txt: Recovery-from-destructive-apply paragraph with
worked example + the full structured-warning + error-code surface.
Promote listed in the CLI deploy-surface bullet list.
sync.test.ts: SURFACE entry { id: deploy_promote, endpoint:
POST /apply/v1/releases/:id/promote, cli: deploy:promote,
openclaw: deploy:promote }; SDK_BY_CAPABILITY mapping to
_applyEngine.promote.
End-to-end verified against the deployed gateway: PROMOTE_TARGET_NOT_FOUND
returns the right code + structured envelope + trace_id when a
nonexistent release is passed. 667 SDK + 32 sync + 244 astro tests pass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The gateway re-runs only the failed phase forward — SQL is never replayed.
324
324
325
+
Recovery from a destructive apply (v1.58+): when an `apply` shipped content the operator regrets (accidental destructive prune, content overwrite, broken release), `run402 deploy promote <release-id>` re-points the project's live release at a prior release row WITHOUT re-running the apply pipeline. No bytes-upload, no bundling, no migration — just a pointer swap on `internal.projects.live_release_id` plus an ssr_cache flush. Designed for "oops on a real project ID" recovery in seconds rather than re-deploying.
326
+
327
+
```bash
328
+
# rel_old (good) → rel_new (bad, destructive) → promote back
Surfaces structured warnings. `MIGRATIONS_NOT_REVERSIBLE` (requires_confirmation: true) fires when the target release predates migrations applied since — the migrations remain applied, so the post-promote release runs against the current schema. Ack with `--allow-warning MIGRATIONS_NOT_REVERSIBLE`. `FUNCTION_VERSION_MISMATCH` (informational) fires when overlapping function names have different code_hashes; the Lambda code is whatever's currently `$LATEST`. Rejected codes: `PROMOTE_TARGET_NOT_FOUND` (release id doesn't exist), `PROMOTE_PROJECT_MISMATCH` (release belongs to another project), `PROMOTE_RELEASE_NOT_READY` (release status not promotable: must be `ready`, `active`, or `superseded`), `PROMOTE_NO_OP` (target IS already the current live; use `cache.invalidateAll` to refresh cache instead), `PROMOTE_WARNING_REQUIRES_ACK` (at least one blocking warning unacked).
334
+
325
335
Inspect deploy history: list recent operations for a project, or pull the recorded phase-event stream for a specific operation (after the fact — for live progress events during an in-flight deploy, the `apply` command already streams them on stderr):
326
336
327
337
```bash
@@ -817,6 +827,7 @@ All admin subcommands require a platform-admin allowance wallet (or an admin OAu
0 commit comments