Error Recovery Patterns
Production logging systems must handle failures gracefully. Network issues, service outages, and resource exhaustion are inevitable. This guide covers patterns for building resilient logging with Vestig.
Transport Failure Handling
HTTPTransportError
The HTTPTransport wraps all errors in HTTPTransportError for consistent handling:
Error Categories
| Property | Status Codes | Description | Should Retry? |
|---|---|---|---|
isNetworkError |
0 | No response received | Yes |
isTimeout |
408 | Request timeout | Yes |
isServerError |
500-599 | Server-side issue | Yes |
isClientError |
400-499 | Client-side issue | No |
isRetryable |
0, 408, 5xx | Combined check | - |
Retry Strategies
Built-in Retries
HTTPTransport and BatchTransport have built-in retry logic:
Exponential Backoff
The transports use exponential backoff with jitter:
Custom Retry Logic
For advanced scenarios, wrap the transport:
Fallback Patterns
Primary/Fallback Transport
Route logs to a fallback when primary fails:
Multi-Destination Logging
Send to multiple destinations for redundancy:
Graceful Degradation
Circuit Breaker Pattern
Prevent cascading failures by stopping requests temporarily:
Sampling Under Load
Reduce log volume when system is stressed:
Buffer Management
Handling Buffer Overflow
The CircularBuffer drops old entries when full:
Persistent Queue
For critical logs, persist to disk:
Initialization Recovery
Async Initialization with Retry
Use createLoggerAsync for transports that need setup:
Fallback During Init
Start with console, upgrade when ready:
Shutdown Handling
Graceful Shutdown
Flush all logs before exit: