Look up an active user task (alpha) Added in 8.11 Physical tenant
POST/user-tasks/:userTaskKey/lookup
Strongly Consistent About endpoint data consistency
Returns an active user task together with the variables visible to it, read from the engine's state instead of secondary storage. The task and its variables are read at the same point in processing, so they are consistent with each other and with any command the engine has already processed, for example the completion of a previous task.
The response includes the task's lifecycle state. Use it to interpret the returned
values: while a change to the task is in progress, the task fields and variables are the
ones from before the change, and state names the pending change. For example, with
ASSIGNING the returned assignee is still the previous one, because task listeners can
deny the new assignment; with COMPLETING the variables don't include the ones sent with
the completion yet.
Only active tasks can be looked up. The lookup returns 404 when the task doesn't exist, when it was already completed or canceled (use the user task search for those), or when it belongs to a tenant the caller isn't assigned to. It returns 409 when the task's process instance is banned: an instance that hit an unrecoverable error and can only be canceled.
Each lookup is processed by the engine. Use it when a task is opened, not for polling.
This endpoint is an alpha feature and may be subject to change in future releases.
Request
Responses
- 200
- 400
- 401
- 403
- 404
- 409
- 500
- 503
The user task and its variables are returned.
The provided data is not valid.
The request lacks valid authentication credentials.
Response Headers
Forbidden. The request is not allowed.
No active user task with the given key is visible to the caller: the task doesn't exist, was already completed or canceled, or belongs to a tenant the caller isn't assigned to.
The user task can't be looked up because its process instance is banned: it hit an unrecoverable error and can only be canceled. More details are provided in the response body.
An internal error occurred while processing the request.
The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains RESOURCE_EXHAUSTED. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .