Skip to main content

Error Handling Guide

Shim returns HTTP 200 for all requests. Check the success field and metadata.errors array.

Why Always HTTP 200?

The Problem: Your LLM app is in production. A malformed JSON response shouldn’t return HTTP 500 and break your frontend. The Solution: Shim returns structured errors in the response body. Your app stays online.

Error Structure

Every error follows this format:

Error Categories

Request Errors

INVALID_REQUEST
  • Missing or invalid parameters
  • Recoverable: No
  • Fix: Check request body
PAYLOAD_TOO_LARGE
  • Input exceeds 5MB
  • Recoverable: No
  • Fix: Use streaming or reduce input

Repair Errors

UNRECOVERABLE_SYNTAX_ERROR
  • JSON structure too malformed to repair after syntax repair
  • Recoverable: No
  • Fix: Check LLM output format
SCHEMA_VALIDATION_FAILED
  • Repaired JSON doesn’t match schema
  • Recoverable: No
  • Fix: Review schema or LLM prompt

Session Errors

SESSION_NOT_FOUND
  • Session expired (60s TTL)
  • Recoverable: Yes
  • Fix: Create new session
BUFFER_SIZE_EXCEEDED
  • Buffer exceeded 5MB (hallucination loop)
  • Recoverable: No
  • Fix: Add max_tokens limit to LLM

Service Errors

SERVICE_UNAVAILABLE
  • Server at capacity
  • Recoverable: Yes
  • Fix: Retry with exponential backoff
RATE_LIMIT_EXCEEDED
  • Exceeded tier limit
  • Recoverable: Yes (after wait)
  • Fix: Upgrade tier or wait

Checking for Errors

Basic Check

Check Recoverability

Check Specific Error Codes


Retry Strategies

Exponential Backoff

Circuit Breaker


Warnings vs Errors

Errors (Critical)

Repair failed. success: false.

Warnings (Non-Critical)

Repair succeeded, but review recommended. success: true.
Handle warnings:

Confidence Levels

Confidence indicates repair safety:
See Confidence Levels for details.

Logging Best Practices

Log Errors with Context

Track Repair Metrics

Alert on Failure Spikes


Fallback Strategies

Fallback to Raw Output

Fallback to Default Value

Retry with Looser Schema


Production Checklist

  • Check success field on every response
  • Log errors with request ID
  • Implement retry logic for recoverable errors
  • Track failure rate metrics
  • Set up alerts for high failure rates
  • Have fallback strategy for critical paths
  • Review low-confidence repairs in logs
  • Monitor repair type distribution

Next Steps

Error Codes

Complete error reference

Confidence Levels

Understand confidence scoring

Rate Limits

Handle RATE_LIMIT_EXCEEDED

Troubleshooting

Common issues and fixes