GetTask, CancelTask, and SubscribeToTask are the task methods documented
here. Like every A2A method they are a POST to the gateway origin — there are
no REST-shaped task routes.
These methods all take a task id you already hold — either the taskId you sent
on the request, or result.task.id from a response that came back in task mode.
Keep it; it is how you get back to the task later.
Task states
Task state is a screaming-snake string on the wire, not a lowercase word.The task object
contextId is the Noorle thread id. artifacts and history are omitted
when empty.
GetTask
Returns the task object. An unknown id returns a task-not-found JSON-RPC error.
CancelTask
Cancellation stops the run. It does not abort a model call already in flight —
that request completes upstream before the run stops.
SubscribeToTask
Reattach to a task and stream its updates. This is the reconnect path when aSendStreamingMessage connection drops.
text/event-stream in the same frame format as
SendStreamingMessage: the current snapshot is
replayed first, then live updates are tailed.
Four outcomes:
Task retention
Task snapshots are stored with a TTL, not kept indefinitely.
A
GetTask on a task that finished more than an hour ago returns not-found.
Read a terminal result promptly, or register a push notification config.
Push notifications
Rather than pollingGetTask, you can register a webhook and have the gateway
POST task updates to it. Four methods manage those targets:
CreateTaskPushNotificationConfig, GetTaskPushNotificationConfig,
ListTaskPushNotificationConfigs, and DeleteTaskPushNotificationConfig.
Terminal and input-required notifications get a reserved lane and are not
dropped to make room for other traffic; intermediate working updates are
best-effort.
Push notifications
Registering a target, the callback body, and what each update guarantees.