Skip to main content

Overview

tif1 implements a robust circuit breaker pattern with exponential backoff retry logic to handle network failures gracefully. This ensures your application remains responsive even when CDN endpoints experience issues.
The circuit breaker prevents cascading failures by “opening” after repeated failures and temporarily blocking requests to give the system time to recover.

Circuit Breaker Pattern

The circuit breaker has three states:

Configuration

Circuit Breaker Settings

Or via environment variables:
Or in ~/.tif1rc:

Default Values

From config.py:50-51:

How It Works

Thread-Safe Implementation

The circuit breaker uses atomic operations with threading locks:

Recording Failures

Failures increment atomically:

Recording Success

Successes reset the counter:

Checking State

Before each request, check if circuit allows the call:

Retry Logic

Exponential Backoff

tif1 uses exponential backoff with jitter for retry delays:

Retry Configuration

Retry Decorator

The @retry_with_backoff decorator wraps functions with retry logic:

Retry Flow

CDN Fallback

tif1 supports multiple CDN sources with automatic fallback.

CDN Manager

The CDNManager tracks multiple CDN sources:

CDN Source

Fallback Logic

When a CDN fails, try the next one:

Disabling Failed CDNs

Configuring CDNs

Never use raw.githubusercontent.com - it has rate limits. tif1 will automatically skip these URLs. Only use cdn.jsdelivr.net or other proper CDNs.

Checking Status

Circuit Breaker State

CDN Health

Reset Circuit Breaker

Manually reset the circuit breaker:

Reset CDN Manager

Ultra Cold Start Mode

For the fastest possible first request, skip retries:
When ultra_cold_skip_retries=True and cache is cold:
This provides the fastest possible response for the first request at the cost of less resilience.

Pool Exhaustion Handling

tif1 detects and handles connection pool exhaustion:

Pool Configuration

Error Handling

Exception Types

tif1 raises specific exceptions for different failure scenarios:

Fatal vs Retryable Errors

Fatal (no retry):
  • DataNotFoundError (404) - data doesn’t exist
  • InvalidDataError - corrupted data
Retryable:
  • NetworkError - connection issues
  • TimeoutError - request timeout
  • HTTP 5xx errors - server issues

Best Practices

Use Defaults

Default settings (5 failures, 60s timeout) work well for most cases

Monitor Logs

Watch for circuit breaker warnings in logs

Handle 404s

DataNotFoundError means data genuinely doesn’t exist

Don't Disable

Keep circuit breaker enabled for resilience

Troubleshooting

Circuit Breaker Keeps Opening

Retries Taking Too Long

All CDNs Failing

Next Steps

Performance

Learn about performance optimization

Validation

Configure data validation

Configuration

Full configuration reference