Skip to main content
client.missionEvents() opens a persistent HTTP connection to the /v8/missions/{runId}/events endpoint and returns a native AsyncGenerator<AuraSseEvent>. The gateway pushes Server-Sent Events over this stream as the mission progresses through its lifecycle — when steps start and complete, when the agent invokes tools, and when the mission reaches a terminal state. Because the generator is lazy, the connection is not opened until you enter the for await loop, and it is closed automatically when the generator finishes or when you break out of the loop.

Basic Usage

Iterate over missionEvents with a standard for await loop. Each iteration yields one AuraSseEvent as soon as the gateway sends it:

AuraSseEvent Structure

Every yielded value is an AuraSseEvent — a plain object with three fields:

Handling Specific Event Types

Branch on event.event to react to individual lifecycle phases:
Always include a default branch (or equivalent) to handle event types you do not recognise. The gateway may emit additional event types in future contract versions without a breaking change.

Cancelling a Stream

Pass an AbortSignal in the options object to cancel the stream from outside the loop. This is useful for enforcing a client-side timeout or for stopping the stream when your application shuts down:
When the signal fires, the SDK cancels the underlying ReadableStream reader and releases its lock. Any in-progress yield resolves with an abort rejection that propagates out of the for await loop as the signal’s reason.

Collecting Final Results

If you want to process all events after the stream closes — for example to extract the mission outcome — collect them into an array and inspect the terminal event:
You can also resume a partially consumed stream by passing the id of the last event you received as lastEventId:
The SSE stream closes automatically when the mission reaches a terminal state: succeeded, failed, or cancelled. You do not need to poll getMission to detect completion — the stream ending is the signal.
Do not rely on event ordering for side effects such as writing to a database or calling an external API. Always check event.event before acting, and treat each event as idempotent where possible. Network interruptions can cause the same event to be delivered more than once if you reconnect with lastEventId.