Skip to main content

Restore a chat after the connection drops

Section: DOC-MA-conversations-streaming-subscribing#receive-updates-and-reconnect.

Restore the user's conversation after a message is sent or a connection is lost. Read the native state endpoint, merge the returned history and reconcile the accepted run before offering another send. An additional subscription may be available for your deployment, but the public reference does not expose a universal streaming URL or replay cursor.

Before a disconnect occurs, keep the conversation ID, the accepted run ID and the messages already displayed. Use the same authenticated user on reconnect. Start with state reads; a live transport is optional and deployment-specific.

Step 1: Reload the original conversation​

Section: DOC-MA-conversations-streaming-subscribing#read-the-current-conversation.

Keep the conversation key and the runId returned when the send is accepted. Reuse the same authorized scope when reading:

curl -X POST https://api.travila.ai/api/v1/llm/conversation-state \
  -H "X-API-Key: sk_your_key_here" \
  -H "X-On-Behalf-Of: user_123" \
  -H "Content-Type: application/json" \
  -d '{
  "conversationKey": "support-chat-001"
}'

Reference: Get full conversation state · Request fields.

Replace the key with your created thread. Follow asynchronous generation for the complete send-and-read loop.

Use the returned history to restore the display, then reconcile the original accepted run. Keep its outcome unresolved when the latest state cannot identify it.

Merge the returned history into the existing view rather than appending another copy of every message. Compare stable message identities and numeric 64-bit sequences; keep sequence strings intact in transport.

Step 2: Resolve the turn or leave it visibly pending​

Section: DOC-MA-conversations-streaming-subscribing#completion-and-recovery.

Poll with a finite deadline and a delay between reads. Respect any Retry-After response. When your wait expires, offer another state refresh without repeating the original message. A lost connection does not prove that generation or a remote tool stopped.

If the result contains pending client tools, follow the client-tool loop. If a subscription reconnects with missing events, refresh authoritative state; receiving the next live event does not fill the gap.

Stop reading and clear private local state on sign-out or scope changes. See interpreting updates for the difference between message, activity and run state.

Finished result: reopening the chat restores its permitted history and the known outcome of the original turn. If that outcome cannot be correlated, the user sees that it is unresolved and can refresh again. No duplicate send is needed to rebuild the view.

For a mobile app returning from the background, run the same state read before trusting the previous spinner or showing a retry. On sign-out, stop reading and clear the private display even if remote work may continue.

Upcoming recipe: resume a mobile chat from retained events​

Status: Upcoming — not yet available.

Section: DOC-MA-conversations-streaming-subscribing#resumable-subscriptions

Restore a mobile chat after a lost connection without losing updates or repeating the user's message. The subscription connects an authorized snapshot to subsequent events and distinguishes a recoverable interruption from a gap beyond retained history.

  1. Authenticate and select the authorized conversation. Its identifier alone does not grant access.
  2. Load the snapshot with its replay boundary and subscribe from that boundary.
  3. Retain the accepted run identity and merge events by stable identity, including duplicates and out-of-order arrivals.
  4. Reconnect in the same scope with the transport's resume cursor, using a finite deadline and backoff.
  5. If the cursor has expired, show the gap and reload permitted state without resending the original message.
  6. Clear private local state on sign-out or scope change, and reauthenticate before resuming.

For example, returning to a chat after a brief disconnect restores the same conversation from its saved cursor. After a longer interruption beyond retention, the client explains the gap and reloads history.

Background suspension, cancellation and a lost connection remain distinct from confirmation that a remote action stopped. The cursor fields and subscription requests are not yet available. The polling recipe above remains the current recovery path; a plain snapshot followed by a live subscription does not guarantee continuity.

Finished result: the client restores the same conversation from retained events, or explains an expired replay gap and reloads permitted history. It never resends the user's message just because the cursor expired.

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