We orchestrate Fly Machines as follows: update with skip_launch=true, retain the returned instance_id, verify preparation, then send one explicit start request. We preserve uncertain outcomes rather than automatically replaying update/start.
Could you clarify the supported API contract?
1. Can a successfully prepared skip_launch Machine remain in created? For an exact instance_id, what supported field, event, or endpoint distinguishes preparation complete from image/rootfs preparation still in progress?
2. If no such read-only signal exists, what sequence do you recommend for starting that instance without another configuration update or an arbitrary delay?
3. When POST /start returns HTTP 412 during preparation, does it guarantee that this request scheduled no subsequent start? Which response details distinguish this from a start already in progress?
We checked the Machines API and state documentation. A supported contract or documentation link would help us avoid duplicate side effects.