talk2me/CONNECTION_RETRY.md
Adolfo Delorenzo 17e0f2f03d Add connection retry logic to handle network interruptions gracefully
- Implement ConnectionManager with exponential backoff retry strategy
- Add automatic connection monitoring and health checks
- Update RequestQueueManager to integrate with connection state
- Create ConnectionUI component for visual connection status
- Queue requests during offline periods and process when online
- Add comprehensive error handling for network-related failures
- Create detailed documentation for connection retry features
- Support manual retry and automatic recovery

Features:
- Real-time connection status indicator
- Offline banner with retry button
- Request queue visualization
- Priority-based request processing
- Configurable retry parameters

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-06-03 00:00:03 -06:00

173 lines
5.1 KiB
Markdown

# Connection Retry Logic Documentation
This document explains the connection retry and network interruption handling features in Talk2Me.
## Overview
Talk2Me implements robust connection retry logic to handle network interruptions gracefully. When a connection is lost or a request fails due to network issues, the application automatically queues requests and retries them when the connection is restored.
## Features
### 1. Automatic Connection Monitoring
- Monitors browser online/offline events
- Periodic health checks to the server (every 5 seconds when offline)
- Visual connection status indicator
- Automatic detection when returning from sleep/hibernation
### 2. Request Queuing
- Failed requests are automatically queued during network interruptions
- Requests maintain their priority and are processed in order
- Queue persists across connection failures
- Visual indication of queued requests
### 3. Exponential Backoff Retry
- Failed requests are retried with exponential backoff
- Initial retry delay: 1 second
- Maximum retry delay: 30 seconds
- Backoff multiplier: 2x
- Maximum retries: 3 attempts
### 4. Connection Status UI
- Real-time connection status indicator (bottom-right corner)
- Offline banner with retry button
- Queue status showing pending requests by type
- Temporary status messages for important events
## User Experience
### When Connection is Lost
1. **Visual Indicators**:
- Connection status shows "Offline" or "Connection error"
- Red banner appears at top of screen
- Queued request count is displayed
2. **Request Handling**:
- New requests are automatically queued
- User sees "Connection error - queued" message
- Requests will be sent when connection returns
3. **Manual Retry**:
- Users can click "Retry" button in offline banner
- Forces immediate connection check
### When Connection is Restored
1. **Automatic Recovery**:
- Connection status changes to "Connecting..."
- Queued requests are processed automatically
- Success message shown briefly
2. **Request Processing**:
- Queued requests maintain their order
- Higher priority requests (transcription) processed first
- Progress indicators show processing status
## Configuration
The connection retry logic can be configured programmatically:
```javascript
// In app.ts or initialization code
connectionManager.configure({
maxRetries: 3, // Maximum retry attempts
initialDelay: 1000, // Initial retry delay (ms)
maxDelay: 30000, // Maximum retry delay (ms)
backoffMultiplier: 2, // Exponential backoff multiplier
timeout: 10000, // Request timeout (ms)
onlineCheckInterval: 5000 // Health check interval (ms)
});
```
## Request Priority
Requests are prioritized as follows:
1. **Transcription** (Priority: 8) - Highest priority
2. **Translation** (Priority: 5) - Normal priority
3. **TTS/Audio** (Priority: 3) - Lower priority
## Error Types
### Retryable Errors
- Network errors
- Connection timeouts
- Server errors (5xx)
- CORS errors (in some cases)
### Non-Retryable Errors
- Client errors (4xx)
- Authentication errors
- Rate limit errors
- Invalid request errors
## Best Practices
1. **For Users**:
- Wait for queued requests to complete before closing the app
- Use the manual retry button if automatic recovery fails
- Check the connection status indicator for current state
2. **For Developers**:
- All fetch requests should go through RequestQueueManager
- Use appropriate request priorities
- Handle both online and offline scenarios in UI
- Provide clear feedback about connection status
## Technical Implementation
### Key Components
1. **ConnectionManager** (`connectionManager.ts`):
- Monitors connection state
- Implements retry logic with exponential backoff
- Provides connection state subscriptions
2. **RequestQueueManager** (`requestQueue.ts`):
- Queues failed requests
- Integrates with ConnectionManager
- Handles request prioritization
3. **ConnectionUI** (`connectionUI.ts`):
- Displays connection status
- Shows offline banner
- Updates queue information
### Integration Example
```typescript
// Automatic integration through RequestQueueManager
const queue = RequestQueueManager.getInstance();
const data = await queue.enqueue<ResponseType>(
'translate', // Request type
async () => {
// Your fetch request
const response = await fetch('/api/translate', options);
return response.json();
},
5 // Priority (1-10, higher = more important)
);
```
## Troubleshooting
### Connection Not Detected
- Check browser permissions for network status
- Ensure health endpoint (/health) is accessible
- Verify no firewall/proxy blocking
### Requests Not Retrying
- Check browser console for errors
- Verify request type is retryable
- Check if max retries exceeded
### Queue Not Processing
- Manually trigger retry with button
- Check if requests are timing out
- Verify server is responding
## Future Enhancements
- Persistent queue storage (survive page refresh)
- Configurable retry strategies per request type
- Network speed detection and adaptation
- Progressive web app offline mode