Error Handling Guide
Shim returns HTTP 200 for all requests. Check thesuccess 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
- 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
- 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 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
- 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.
Confidence Levels
Confidence indicates repair safety:| Level | Meaning | Action |
|---|---|---|
high | Structural fixes only, or perfect input | Use immediately |
medium | Schema repairs or warnings | Review in logs |
low | Ambiguous repairs | Manual review |
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
successfield 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
