You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(sdk): enrich transport events with correlation and timing fields
Send events gain partId (the append idempotency key, also on the
server-side record) and bodyBytes. Response events gain client-side
attribution: messageId of the last turn-producing send plus sinceSendMs,
so time-to-first-token and full-turn latency need no consumer
bookkeeping. first-chunk carries chunkType and its record id,
turn-completed carries the agent's committed input cursor, and
stream-error carries the HTTP status when one exists.
Copy file name to clipboardExpand all lines: docs/ai-chat/frontend.mdx
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -615,4 +615,4 @@ onEvent: (event) => {
615
615
};
616
616
```
617
617
618
-
Time to first token is the delta between a `message-sent` and the following `first-chunk` on the same chat. Exceptions thrown inside `onEvent` are swallowed, so a failing metrics pipeline can never break the chat.
618
+
Time to first token is `first-chunk`'s `sinceSendMs` (the transport tracks the last turn-producing send per chat, so no bookkeeping is needed), and `turn-completed`'s `sinceSendMs` is the full turn latency. Exceptions thrown inside `onEvent` are swallowed, so a failing metrics pipeline can never break the chat.
Copy file name to clipboardExpand all lines: docs/ai-chat/reference.mdx
+8-6Lines changed: 8 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -641,15 +641,17 @@ The `onEvent` callback receives a `ChatTransportEvent` (exported from `@trigger.
641
641
642
642
| Event | Extra fields | Fires when |
643
643
| --- | --- | --- |
644
-
|`message-sent`|`messageId?`, `source`, `durationMs`| A send was durably acknowledged — a 2xx from the session input stream append (or the `headStart` POST), after any internal token-refresh retries. This means the message is durably written to the stream the agent consumes from, not merely "request accepted". |
645
-
|`message-send-failed`|`messageId?`, `source`, `error`, `status?`, `durationMs`| A send definitively failed after internal retries. Fires in addition to `useChat`'s `onError`. |
646
-
|`stream-connected`|`resumed`| The SSE subscription to the session's output stream started delivering. `resumed: true` when reconnecting from a stored cursor (page reload) rather than following a fresh send. |
647
-
|`first-chunk`|— | The first response chunk of a turn arrived. Pair with `message-sent` for time-to-first-token. |
648
-
|`turn-completed`|`lastEventId?`| The agent's turn-complete control record arrived — the "finished answering" signal. |
649
-
|`stream-error`|`error`| The output stream failed unrecoverably. |
644
+
|`message-sent`|`messageId?`, `source`, `durationMs`, `partId?`, `bodyBytes?`| A send was durably acknowledged — a 2xx from the session input stream append (or the `headStart` POST), after any internal token-refresh retries. This means the message is durably written to the stream the agent consumes from, not merely "request accepted". `partId` is the append's idempotency key, also stored on the server-side record. |
645
+
|`message-send-failed`|`messageId?`, `source`, `error`, `status?`, `durationMs`, `partId?`, `bodyBytes?`| A send definitively failed after internal retries. Fires in addition to `useChat`'s `onError`. |
646
+
|`stream-connected`|`resumed`, `lastEventId?`, `messageId?`| The SSE subscription to the session's output stream started delivering. `resumed: true` when reconnecting from a stored cursor (page reload) rather than following a fresh send. `lastEventId` is the cursor it connected from. |
647
+
|`first-chunk`|`chunkType?`, `lastEventId?`, `messageId?`, `sinceSendMs?`| The first response chunk of a turn arrived. `sinceSendMs` is the delta from the last turn-producing send — time to firsttoken without any bookkeeping. |
648
+
|`turn-completed`|`lastEventId?`, `sessionInEventId?`, `messageId?`, `sinceSendMs?`| The agent's turn-complete control record arrived — the "finished answering" signal. `sinceSendMs` is the full turn latency; `sessionInEventId` is the agent's committed input-stream cursor. |
649
+
|`stream-error`|`error`, `status?`| The output stream failed unrecoverably. |
650
650
651
651
`source` identifies the send path: `"submit-message"`, `"regenerate-message"`, `"steer"` (`sendPendingMessage`), `"action"` (`sendAction`), `"stop"` (`stopGeneration`), or `"head-start"`.
652
652
653
+
`messageId` on the response-side events is client-side attribution: the id from the most recent turn-producing send (`submit-message`, `regenerate-message`, or `head-start`) on that chat.
654
+
653
655
See [Monitoring message delivery](/ai-chat/frontend#monitoring-message-delivery) for the metrics and watchdog patterns these enable.
0 commit comments