> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mob.exchange/llms.txt
> Use this file to discover all available pages before exploring further.

# Task lifecycle

> Track asynchronous execution and handle queued operations.

| State                                                                | Meaning for API clients                                                   |
| -------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| `pending`                                                            | Queued for the worker; can be cancelled.                                  |
| `ordering`                                                           | Opening is in progress.                                                   |
| `running`                                                            | Open position; can be resized or closed unless `closeRequestedAt` is set. |
| `resizing`, `closing`                                                | Requested mutation is being processed.                                    |
| `neutralizing`, `trimming`, `mismatch_checking`, `leg_gone_checking` | Worker recovery or protection in progress.                                |
| `closed`, `cancelled`, `failed`                                      | Terminal states.                                                          |

Poll `GET /v1/delta-neutral/tasks/:taskId` for completion. A successful `POST` does not imply that a later worker operation will succeed.

One wallet owner can have only one task in an order-mutating state (`ordering`, `neutralizing`, `trimming`, `resizing`, or `closing`) at a time because its venue accounts are shared. You may create multiple `pending` tasks, but the worker opens them serially. A `close` request is durable even while another task is active: the worker promotes the oldest queued close as soon as that owner's active operation releases the mutation slot, before opening another pending task. It cannot interrupt an operation already in progress. A `resize` for a different task while one is active still returns `409 owner_busy`; retry with a new `Idempotency-Key` after the active operation finishes. Reuse the original key only when retrying an uncertain response to the same attempt.