corsair.ts
Error handler hierarchy
Corsair checks for error handlers in this order:- Plugin-specific error: e.g., Slack rate limit handler
- Root-level error: e.g., global rate limit handler for all integrations
- Plugin default: e.g., default Slack error handler
- Root default: default handler for all integrations
- Corsair fallback: built-in handler that fails gracefully
Plugin-level handler
Handle errors specific to a single integration.corsair.ts
Root-level handler
Handle errors across all integrations.corsair.ts
Default handler
Catch any error that doesn’t match a specific handler.corsair.ts
No handler needed
You don’t have to define any error handlers. Corsair provides sensible defaults that ensure your application fails gracefully. Start simple and add handlers as needed.corsair.ts
Retry strategies
When returning from an error handler, you can specify:maxRetries: number of retry attemptsretryStrategy:"exponential_backoff_jitter"or other strategies
Reconnect and auth-missing
The handlers above cover errors from a connected integration. When a tenant hasn’t connected a plugin yet, or a stored token can no longer be refreshed, Corsair throws a typed error carrying the connect link instead:AuthMissingError— no usable credential for the tenant. Send them through a connect flow.ReconnectRequiredError— a stored connection went stale (for example, a revoked refresh token). Same fix: reconnect.
call. Anywhere else, read error.connectUrl and route the user there.