Get rollback status
get_rollback_statusProgress and final result of a rollback started with rollback_commit (by rollback_id), or of a project's most recent rollback (by project_id, for when the rollback_id is not at hand). status is running, done or failed. running: not finished — message says whether production has switched and whether the data is restored yet. done: production runs the target commit and, in restore_data mode, the app is running on the restored data. failed: the rollback stopped and will not continue by itself; error is the reason, message says what changed and what did not, code_moved and data_state say the same as fields (data_state is untouched, in_progress, restored, partial or unknown; data_restored is true only for restored), and next says what to do — which after a failure is not always to run the rollback again. steps lists each step with its state. wait_s (max 55) blocks until the rollback ends instead of returning at once; retry_after_s, when present, is the polling interval and its absence means the status is final. The answer is read from stored state, so a dropped call or a timeout loses nothing.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| wait_s | No | optional: block up to this many seconds (max 55) for the rollback to end and return the moment it does. 0 or absent returns the status at once | |
| project_id | No | the project id: reports the project's most recent rollback. For when the rollback_id is not at hand (the rollback_commit reply was lost, or the rollback was started from the dashboard or from an approved plan) | |
| rollback_id | No | the rollback_id that rollback_commit returned. Give this or project_id |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | keep_data or restore_data, as passed to rollback_commit | |
| next | Yes | what to do now, in plain words | |
| step | No | the step running now, or the step that failed | |
| error | No | set when status is failed: the reason | |
| steps | Yes | ||
| commit | No | ||
| job_id | Yes | the deployment the rollback targets | |
| status | Yes | running (not finished: the code may have moved and the data may not be restored yet), done (finished: production runs the target commit and, in restore_data mode, the app is running on the restored data), or failed (stopped before the end: message says what changed and what did not) | |
| message | Yes | ||
| point_id | No | ||
| waited_s | No | seconds this call blocked (wait_s) | |
| code_moved | Yes | true when production was switched to the target commit by this rollback. Can be true on a failed rollback | |
| data_state | Yes | what this rollback did to the app's data: untouched (no disk was written), in_progress (the rollback is still working on the disks), restored (every disk was copied back and verified), partial (a disk was written and the restore is not whole: a copy stopped part-way, or one disk was restored and another was not), unknown (the rollback was cut while it worked on the disks) | |
| project_id | Yes | ||
| started_at | No | ||
| finished_at | No | ||
| rollback_id | Yes | ||
| data_restored | Yes | true only when data_state is restored: every disk was copied back and verified. It is false while the rollback runs, and false after a copy that stopped part-way even though that disk was overwritten: data_state says which | |
| retry_after_s | No | wait at least this many seconds before calling get_rollback_status again; absent means the status is final | |
| safety_point_id | No | the restore point holding the data as it was just before this rollback overwrote it. rollback_commit with the canonical commit's job_id, mode=restore_data and this point_id puts that data back |