Error Handling

Retrieve provides robust error handling mechanisms to ensure your integrations are reliable, recoverable, and maintainable. When things go wrong (and they will), you need visibility, control, and automated recovery options.

🛡️ Why Error Handling Matters

  • Reliability - Automatically retry failed operations without manual intervention
  • Visibility - Get notified when integrations fail with detailed error information
  • Control - Configure retry behavior and notification thresholds per integration
  • Debugging - Access comprehensive logs to diagnose and fix issues quickly

Understanding Job Failures

In Retrieve, every integration run is a "job". Jobs can fail for various reasons:

Common Failure Scenarios

🔌 Connection Failures

Cause: Unable to connect to source or destination system

Examples: API timeout, database connection refused, network error, authentication failed

Recovery: Usually transient - automatic retry often resolves

📊 Data Validation Errors

Cause: Data doesn't meet requirements or constraints

Examples: Missing required fields, invalid format, duplicate key violation

Recovery: Requires data correction - investigate and fix source data

⚠️ API Rate Limits

Cause: Exceeded API request limits

Examples: 429 Too Many Requests, quota exceeded

Recovery: Wait and retry - configure appropriate retry delays

💥 Runtime Errors

Cause: Code execution errors in rewrite functions

Examples: Undefined variable, type error, null reference

Recovery: Fix the code - review and update rewrite function

🚫 Authorization Errors

Cause: Invalid or expired credentials

Examples: 401 Unauthorized, expired OAuth token, invalid API key

Recovery: Update credentials - refresh tokens or regenerate keys

Automatic Retry Mechanism

Retrieve can automatically retry failed jobs, which is especially useful for transient errors like network issues or temporary API outages.

Configuring Retry Behavior

For each integration, you can configure:

✅ Enable Retry

Turn on automatic retry for failed jobs

⏱️ Retry Time

How long to wait before retrying (e.g., 5 minutes, 1 hour)

🔄 Max Retry Attempts

How many times to retry before giving up

How Retry Works

1

Job Fails

Integration encounters an error during execution

2

Check Retry Setting

Retrieve checks if retry is enabled for this integration

3

Wait for Retry Time

System waits for the configured retry delay (e.g., 5 minutes)

4

Retry Job

Job is automatically queued and executed again with the same data

5

Success or Max Attempts

Either job succeeds, or max retry attempts reached

Best Practices for Retry Configuration

Use Exponential Backoff

Start with short retry delays (5 min) and increase if failures persist. This prevents overwhelming failing systems.

Limit Retry Attempts

Set max 3-5 retries for most integrations. Infinite retries can mask underlying issues.

Consider Error Type

Retry makes sense for network errors and rate limits, but not for data validation errors.

Monitor Retry Patterns

Frequent retries indicate systemic issues. Investigate and fix root causes.

Email Notifications

Retrieve includes a powerful notification engine that alerts you when integrations fail, so you can take action before issues escalate.

Notification Features

📧 Email Alerts

Receive detailed email notifications when jobs fail

🎯 Smart Thresholds

Set how many failures before sending an alert

👥 Multiple Recipients

Add multiple team members to receive notifications

🔍 Error Details

Get complete error messages and stack traces in emails

Setting Up Notifications

Configure notifications in your integration settings:

  1. Enable Notifications

    Turn on "Notify (if it fails)" in integration settings

  2. Set Failure Threshold

    Configure how many consecutive failures trigger a notification (e.g., 3 failures)

    Threshold = 3 means:
    - 1st failure: No notification (waiting...)
    - 2nd failure: No notification (waiting...)
    - 3rd failure: ✉️ Email sent to all recipients
  3. Add Recipients

    Add email addresses of people who should be notified:

    • Name: Person's name for identification
    • Email: Where to send the notification
    • Type: Admin or Customer user
    • Language: Preferred notification language

Understanding Failure Thresholds

The notification threshold prevents alert fatigue by only notifying after multiple consecutive failures:

Threshold = 1

✉️ Notifies on first failure

Use for: Critical real-time integrations

Threshold = 5+

✉️ Notifies after 5+ consecutive failures

Use for: Non-critical integrations with frequent transient errors

Notification Email Content

When a notification is triggered, you receive an email containing:

  • Integration Name - Which integration failed
  • Failure Count - How many times it has failed consecutively
  • Error Message - Detailed error description
  • Timestamp - When the failure occurred
  • Job ID - Link to view full job details in the dashboard
  • Stack Trace - Technical details for debugging (if available)

Notification Best Practices

Set Appropriate Thresholds

Use threshold = 3 for most integrations to avoid noise from transient errors

Add Multiple Recipients

Include both primary and backup contacts to ensure someone can respond

Use Distribution Lists

Add team email addresses (e.g., ops@company.com) for better coverage

Test Notifications

Verify notifications are working by temporarily setting threshold = 1 and triggering a test failure

Document Response Procedures

Create a runbook for your team on how to respond to different types of failures

Job History & Logs

Every job execution is logged in the Retrieve dashboard, providing complete visibility into successes, failures, and errors.

Accessing Job History

  1. Navigate to Job History in the Retrieve dashboard
  2. Filter by integration, date range, or status (success/failed)
  3. Click any job to view detailed execution logs

What's Logged

📅 Execution Timestamp

Exact time the job started and completed

✅ Job Status

Success, Failed, or In Progress

📊 Data Processed

Number of records fetched and pushed

⏱️ Duration

How long the job took to execute

🔍 Error Details

Complete error messages and stack traces for failures

🔄 Retry Information

Which attempt number, next retry time

Error Handling in Rewrite Functions

You can implement custom error handling logic in your rewrite functions to gracefully handle issues:

Try-Catch for Error Handling

let job = jobData.job;
let sourceData = job.data.data;

try {
  // Attempt to process data
  let processedData = sourceData.map(item => {
    // Your transformation logic
    return {
      id: item.id,
      name: item.customer.name, // Could fail if customer is null
      email: item.customer.email
    };
  });
  
  return {
    jobStatus: 1, // Success
    data: processedData
  };
  
} catch (error) {
  console.error('Error processing data:', error.message);
  
  return {
    jobStatus: 0, // Failed
    data: [],
    message: `Failed to process data: ${error.message}`
  };
}

Conditional Data Processing

Skip invalid records instead of failing the entire job:

let job = jobData.job;
let orders = job.data.data;

// Filter out invalid orders instead of failing
let validOrders = orders.filter(order => {
  // Check if order has required fields
  if (!order.id || !order.customer_email) {
    console.log(`Skipping invalid order: ${JSON.stringify(order)}`);
    return false;
  }
  return true;
});

console.log(`Processing ${validOrders.length} of ${orders.length} orders`);

return {
  jobStatus: 1,
  data: validOrders,
  message: `Processed ${validOrders.length} valid orders, skipped ${orders.length - validOrders.length}`
};

Custom Error Responses

Return specific error information to help with debugging:

let job = jobData.job;

// Validate configuration
if (!job.config.api_key) {
  return {
    jobStatus: 0,
    data: [],
    message: 'Missing API key in integration configuration. Please add API key in settings.'
  };
}

// Validate data
if (!job.data.data || job.data.data.length === 0) {
  return {
    jobStatus: 1, // Success, but no data
    data: [],
    message: 'No records to process - source returned empty result'
  };
}

Common Error Patterns & Solutions

❌ Error: "ECONNREFUSED" or "Connection Timeout"

Cause: Cannot reach the API or database server

Solutions:

  • Verify the server is online and accessible
  • Check firewall rules and network connectivity
  • For private servers, ensure Tailscale VPN is connected
  • Enable retry - this is usually a transient error

❌ Error: "401 Unauthorized" or "403 Forbidden"

Cause: Invalid or expired credentials

Solutions:

  • Regenerate API keys or tokens
  • Update credentials in integration settings
  • Check OAuth token expiration and refresh if needed
  • Verify account permissions haven't changed

❌ Error: "429 Too Many Requests"

Cause: API rate limit exceeded

Solutions:

  • Reduce integration frequency (run less often)
  • Enable retry with longer delay (e.g., 1 hour)
  • Implement batching to reduce API calls
  • Contact API provider about rate limit increases

❌ Error: "Cannot read property 'X' of undefined"

Cause: Accessing a field that doesn't exist in the data

Solutions:

  • Add null checks in rewrite functions
  • Use optional chaining: data?.field?.nested
  • Provide default values: data.field || 'default'
  • Review field mapping for missing or renamed fields

❌ Error: "Duplicate entry" or "Unique constraint violation"

Cause: Trying to create a record that already exists

Solutions:

  • Implement update logic instead of insert
  • Use "upsert" operations (update if exists, insert if not)
  • Check for existing records before pushing
  • Review integration logic to prevent duplicates

Monitoring Integration Health

Proactive monitoring helps you catch issues before they become critical:

Key Metrics to Track

📈 Success Rate

Percentage of jobs completing successfully

Target: >95%

⏱️ Execution Time

How long jobs take to complete

Monitor for increases

🔄 Retry Frequency

How often jobs are being retried

Low is better

📊 Records Processed

Volume of data being synced

Monitor for drops

Regular Health Checks

  • ✅ Review job history weekly for failure patterns
  • ✅ Monitor notification emails and investigate repeated failures
  • ✅ Test integrations after credential updates or API changes
  • ✅ Keep integration packages updated to latest versions
  • ✅ Document common errors and their solutions for your team

Next Steps