Tasks

Starts a new sync task on appId, routing the request body payload to an available worker. The request blocks until the task is terminal and returns the result inline (200). Resubmitting a task id waits on the task it already names rather than starting a second one, so the 200 carries that task's result and may name a different appId. Poll it under the one returned. A task that outlives the wait window is not a failure: the task is still queued or running, and the response is 202 carrying that task with status: pending, the same shape invoke-async returns, and it names the owning appId on a resubmission just as the 200 does. Poll GET /v1/apps/{appId}/tasks/{taskId} for its result. A request the platform cannot attribute to an accepted task fails instead, with no task to poll. Apps in initializing, active, or stopping accept invocation, with two exceptions: an initializing app whose first rollout has not produced a version returns 409 Conflict, and an active app the platform has observed to have no workload able to serve returns 503 Service Unavailable with no task minted, typed capacity-unavailable and carrying Retry-After. stopped, deleting, and failed return 409 Conflict. Unknown or deleted apps return 404 Not Found. An organization whose serverless tenancy is revoked, or has no tenancy receipt at all, returns 403 Forbidden, distinguishing that from an app that does not exist. An organization whose tenancy is still being provisioned returns 503 Service Unavailable instead. That state is retryable, not a revocation, and clears once provisioning finishes. Endpoint membership is checked against the active version's endpoint set before the task is accepted: an endpoint the app does not declare returns 404 whose endpointPath extension member carries the rejected path, distinguishing it from an unknown app, and the task never enters the queue.

Starts a new async task on appId, routing the request body payload to an available worker. The task runs asynchronously and the response is 202. Poll GET /v1/apps/{appId}/tasks/{taskId} for completion. Resubmitting a task id is answered with the task it already names rather than starting a second one, so the 202 can carry a task that has already finished: read its status instead of assuming pending, and note it may name a different appId. Apps in initializing, active, or stopping accept invocation, with two exceptions: an initializing app whose first rollout has not produced a version returns 409 Conflict, and an active app the platform has observed to have no workload able to serve returns 503 Service Unavailable with no task minted, typed capacity-unavailable and carrying Retry-After. stopped, deleting, and failed return 409 Conflict. Unknown or deleted apps return 404 Not Found. An organization whose serverless tenancy is revoked, or has no tenancy receipt at all, returns 403 Forbidden, distinguishing that from an app that does not exist. An organization whose tenancy is still being provisioned returns 503 Service Unavailable instead. That state is retryable, not a revocation, and clears once provisioning finishes. Endpoint membership is checked against the active version's endpoint set before the task is accepted: an endpoint the app does not declare returns 404 whose endpointPath extension member carries the rejected path, distinguishing it from an unknown app, and the task never enters the queue.

Returns the task's current status, read through the inference transport layer from the shared result store. When completed, includes the result output and completedAt. When failed, includes error. When pending, neither is set. If the app is stopped, deleting, or failed, accepted task results stay readable. A 404 Not Found means the task cannot currently be verified for this app. Because enqueue-time ownership tracking is best effort, a recently returned task ID can temporarily return 404. Retry it within the normal polling window. Unknown or deleted apps also return 404 Not Found.

Lists TTL-bounded asynchronous task metadata for this app so a client can recover task ids after an interrupted long-poll or CLI session. Pending includes queued, running and retrying work. Tasks appear only within the configured recovery window. A page can be empty and still have nextCursor. Continue until it is null. Pending entries are best effort and may disappear if the recovery store restarts. Tracked tasks reappear on completion. This is not persisted task history. A task id names one task, so resubmitting one does not add a second entry here. If the app is stopped, deleting, or failed, recovery stays available. Unknown or deleted apps return 404 Not Found.