Operations and ?wait

Lifecycle and image operations may return 202 while physical work continues. Preserve the operation ID and relevant computer, snapshot or image ID before waiting. Poll GET /operations/{id}. Lifecycle requests also accept an optional ?wait=N (N up to 60 seconds) that holds the request open; if it runs out, the API returns 202 with the operation.

Observe completion

The public states are pending, running, succeeded and failed. Acceptance and completion are separate responses. A succeeded operation still needs its declared final resource projection checked when the SDK waiter promises a particular state. A failed operation carries the original Problem; inspect retryable and Retry-After rather than relying on status alone.

SDK create/start/resume/restart/pause/stop methods have bounded local waiters. Timeout retains recovery identity and does not cancel the server job. Delete returns on acceptance or a no-op result; physical deletion and the later purge remain separate. Snapshot/image operations can similarly return a synchronous object or an accepted envelope.

Competing lifecycle requests

A newer authorized lifecycle action can supersede an earlier request. The old operation becomes failed with 409, retryable false, detail “Superseded by a newer lifecycle request” and a finished timestamp. A stale worker cannot use the old operation to restart the computer after supersession. Poll the retained operation rather than treating any later running state as proof that the old request completed.

Use Idempotency to recover a lost acceptance response. Read Lifecycle before translating an operation into a user-facing status. Operation history and present resource state describe different times; neither should be relabeled as the other.

Dory is in development; these pages describe the planned service and may change. Questions: support@computeengines.com.