Skip to main content

Keep a chat reply current while the user waits

Section: DOC-MA-conversations-streaming#receive-conversation-updates.

Keep your chat display up to date with conversation-state reads. If your deployment also provides live updates, use its connection instructions and refresh state after a disconnect.

The native /api/v1/llm/ operations do not use the OpenAI wire protocol. An OpenAI SDK cannot call them by changing its base URL alone.

For the first implementation, choose asynchronous send plus state reads. You need an authenticated thread and the run ID retained from the send. Add deployment-specific live updates only after the same read/recovery path works.

Recipe: update the reply and recover a dropped connection​

Section: DOC-MA-conversations-streaming#get-replies-with-the-current-api.

  1. Send the question once and retain its conversation and run IDs.
  2. Read conversation state at a bounded interval while the user waits. Merge stored messages by stable identity and numeric sequence.
  3. Show the accepted run as working, waiting for input, completed, failed, cancelled or unknown according to its correlated outcome. A finished tool round or idle conversation alone cannot complete the question.
  4. On disconnect, show reconnecting and refresh the same conversation. Keep uncertainty visible if the latest state belongs to a different run.
  5. At the client deadline, stop automatic reads and offer a refresh. Do not submit another message to recover status.

Finished result: the customer sees one copy of their question and reply, with a truthful pending, completed or unsuccessful outcome. A timer never turns a stale spinner into success.

For a backend that needs a bounded inline response, use synchronous generation instead. It still requires outcome checks.

Variant: add live updates available in your deployment​

Section: DOC-MA-conversations-streaming#integrate-a-qualified-streaming-transport.

Follow the deployment's connection instructions, load the current authorized state and use live updates to keep the view responsive. Retain the state-read path for reconnect and missing events. A snapshot plus a live subscription is not automatically gap-free.

The public API reference does not provide a universal subscription URL or replay cursor. Use the state-read recovery flow in receiving updates and the field interpretation in interpreting updates. A deployment-specific subscription does not replace authoritative state reads.

See API conventions for the current native protocol and conversation generation for reply handling.

Upcoming recipe: stream a reply through the client’s chosen protocol​

Status: Upcoming — not yet available.

Section: DOC-MA-conversations-streaming#native-and-compatible-streams

Choose native conversation run events when the client needs Travila run/tool status, or a supported OpenAI Responses or Chat Completions interface for an application using that protocol. A self-hosted deployment path supports these streaming workflows.

  1. Start with that transport’s authentication and event contract.
  2. Keep the accepted run and individual attempt distinct while displaying partial answer content provisionally.
  3. Continue complete tool calls through the matching protocol.
  4. Follow the reconnection flow after a disconnect and use event identities and outcomes to reconcile the final result.

Finished result: incremental output leads to a recognizable terminal outcome. Native and compatible payloads stay within their own protocol; provisional text does not complete the run.

Each transport defines its own authentication, event schema, terminal outcomes, replay boundary and retention limits. Subscription URLs and SDK setup for these interfaces are not yet available. Current native REST operations retain their existing protocol.

Document ID: DOC-MA-conversations-streaming. Section identities and revisions.