For the complete documentation index, see llms.txt. This page is also available as Markdown.

Error Handling & Reconnect

Handle server errors, stream failures, and connection drops in Titan Direct integrations.

Titan Direct is a persistent WebSocket connection. Connections drop, tokens expire, and streams end unexpectedly. This guide covers every failure mode and how to build a reconnect loop that keeps your integration running.

Server messages

The server sends one of four message types — Response, Error, StreamData, or StreamEnd. See Types Reference for the full type definitions.

Server errors

When a request fails, the server sends an Error instead of a Response. Check for the Error key in every message handler:

ws.on('message', async (raw: Buffer) => {
  const msg = await decodeMessage(raw);

  if ('Error' in msg) {
    const { code, message, requestId } = msg.Error;
    console.error(`Request ${requestId} failed — code ${code}: ${message}`);
    return;
  }
});

Stream errors

A stream can end abnormally. StreamEnd carries an optional errorCode and errorMessage — if present, the stream did not terminate cleanly:

Connection drops

When the WebSocket closes, all active streams are dead. Listen for the close event and trigger your reconnect logic:

Token expiry

The server refuses connections where the JWT exp claim is in the past. If your connection is rejected immediately, check that your token is still valid before reconnecting:

Refresh your token before calling connect() if it's close to expiry.

Reconnect with exponential backoff

The SDK has no built-in reconnect — it's your responsibility. Here's a complete reconnect loop:

Best practices

  • Call GetInfo after every reconnect to confirm the server is reachable before opening streams.

  • If a route has expiresAtMs or expiresAfterSlot set, check these before building a transaction — a quote valid when received can go stale by the time it lands on-chain.

  • Keep your reconnect loop separate from your quote processing logic so a stream error doesn't silently kill the reconnect handler.


Last updated