Skip to main content
Error codes, recovery strategies, and best practices for ABP error handling.

Error Response Format

All ABP errors follow this structure:

Standard Error Codes

Session Errors

Capability Errors

Parameter Errors

Permission Errors

Execution Errors

System Errors

Transport Errors

MCP Bridge Error Handling

When using the ABP MCP Bridge, errors are surfaced as structured MCP responses with isError: true. The bridge adds context-specific error information beyond what the ABP protocol itself defines.

Connection Errors

Capability Call Errors

ABP apps return structured errors with error codes. The bridge forwards these with retryable flags: Error responses include the retryable flag: "TIMEOUT: Operation timed out (retryable)".

Browser Errors

The bridge detects browser context loss (detached frame, target closed, session closed) and surfaces clean error messages. If the browser disconnects unexpectedly, the bridge logs a warning and resets internal state. A new abp_connect call will launch a fresh browser. The BrowserEventGuard monitors for page crashes and page closures. If either occurs, the bridge status is set to error with a descriptive message, and subsequent abp_call attempts will return "Browser page is no longer available — reconnect with abp_connect" instead of cryptic “Target closed” errors. Dialogs (alert, confirm, prompt, beforeunload) are auto-handled by the guard so they never block capability execution. The guard logs every handled dialog for debugging (ABP_LOG_LEVEL=info). See Troubleshooting for step-by-step resolution of common errors.

Error Handling Patterns

Client-Side (Agent/Bridge)

App-Side (Implementation)

Graceful Degradation

When a capability fails, the error response may include an alternatives array suggesting fallback capabilities. Use this to degrade gracefully:

Retry Strategies

Exponential Backoff

Best Practices

  1. Always check success flag: Don’t assume success
  2. Respect retryable flag: Don’t retry non-retryable errors
  3. Use exponential backoff: Prevent overwhelming the app
  4. Log errors: Include error codes for debugging
  5. Provide alternatives: Suggest fallback capabilities
  6. Handle gracefully: Don’t crash on capability errors

Next Steps

Cancellation

Cancellation error handling

Examples & Tutorials

Working code examples

API Reference

Full API specification