Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/iii-hq/sdk/llms.txt

Use this file to discover all available pages before exploring further.

The ReconnectionConfig type controls how the III SDK reconnects to the engine when the WebSocket connection is lost.

Type Definition

interface ReconnectionConfig {
  initialDelayMs: number
  maxDelayMs: number
  backoffMultiplier: number
  jitterFactor: number
  maxRetries: number
}

Fields

Default Configuration

const DEFAULT_RECONNECTION_CONFIG: ReconnectionConfig = {
  initialDelayMs: 1000,
  maxDelayMs: 30000,
  backoffMultiplier: 2,
  jitterFactor: 0.3,
  maxRetries: -1  // infinite
}

Usage Examples

Fast Reconnection

For local development or low-latency requirements:
const iii = init('ws://localhost:49134', {
  reconnectionConfig: {
    initialDelayMs: 100,
    maxDelayMs: 5000,
    backoffMultiplier: 1.5,
    jitterFactor: 0.2,
    maxRetries: -1
  }
})

Limited Retries

For batch jobs or scripts that should fail fast:
const iii = init('ws://localhost:49134', {
  reconnectionConfig: {
    initialDelayMs: 1000,
    maxDelayMs: 10000,
    backoffMultiplier: 2,
    jitterFactor: 0.3,
    maxRetries: 5  // Give up after 5 attempts
  }
})

No Automatic Reconnection

For testing or manual connection management:
const iii = init('ws://localhost:49134', {
  reconnectionConfig: {
    initialDelayMs: 1000,
    maxDelayMs: 1000,
    backoffMultiplier: 1,
    jitterFactor: 0,
    maxRetries: 0  // Never retry
  }
})

Connection State Monitoring

You can monitor connection state changes to react to reconnection events:
// Connection states: 'disconnected' | 'connecting' | 'connected' | 'reconnecting' | 'failed'

iii.onConnectionStateChange((state) => {
  console.log('Connection state:', state)
  
  if (state === 'reconnecting') {
    console.log('Attempting to reconnect...')
  } else if (state === 'connected') {
    console.log('Reconnected successfully!')
  } else if (state === 'failed') {
    console.error('Max retries exceeded, connection failed')
  }
})

Behavior During Reconnection

Message Queueing

When the connection is lost:
  1. Outgoing messages are queued in memory
  2. On reconnect, all registrations (functions, triggers, services) are re-sent
  3. Queued invocations are sent after reconnection
  4. Duplicate registrations are automatically deduplicated

Pending Invocations

Active function invocations during disconnect:
  • TypeScript/Python: Remain pending, will timeout if not completed within invocationTimeoutMs
  • Rust: Subject to max_pending_messages limit, excess messages are dropped

State Preservation

  • ✅ Function registrations
  • ✅ Trigger registrations
  • ✅ Service registrations
  • ✅ Trigger type handlers
  • ❌ Active WebSocket connections (channels)
  • ❌ In-flight HTTP streaming responses

Best Practices

  1. Production environments: Use default config with infinite retries
  2. Development: Reduce delays for faster feedback
  3. Batch jobs: Limit retries to fail fast
  4. High-traffic: Increase jitterFactor to prevent thundering herd
  5. Monitoring: Always monitor connection state in production

Build docs developers (and LLMs) love