This commit addresses several critical race conditions and improves the reliability
of etcd operations through better timeout and retry handling.
## Race Condition Fixes
1. **Task Resource Management Bug**
- Fixed incorrect variable usage in task/list.go:78
- Was using completed task's resources instead of idle task's resources
- This caused resource conflicts and potential deadlocks
2. **Database Channel Initialization**
- Added sync.Once pattern to ensure thread-safe channel initialization
- Prevents panic from concurrent access during startup
- Created initDBRequests() function for safe initialization
3. **Published Storage Double-Checked Locking**
- Implemented double-checked locking pattern in GetPublishedStorage
- Reduces lock contention while preventing concurrent initialization
- Improves performance for frequently accessed storage
4. **File Operation Synchronization**
- Created FileLockRegistry in utils/filelock.go
- Prevents concurrent file operations (create, rename, delete, link)
- Implements deadlock prevention for multi-file operations
- Critical for preventing file corruption during parallel publishes
5. **WaitGroup Miscount Prevention**
- Added defer pattern to ensure Done() is always called
- Protects against panics during task execution
- Prevents "negative WaitGroup counter" errors
## etcd Improvements
1. **Timeout Protection**
- Replaced global context.TODO() with per-operation timeout contexts
- Default timeout: 60 seconds (configurable)
- Prevents indefinite hangs when etcd is unresponsive
2. **Environment Variable Configuration**
- APTLY_ETCD_TIMEOUT: Operation timeout (default: 60s)
- APTLY_ETCD_DIAL_TIMEOUT: Connection timeout (default: 60s)
- APTLY_ETCD_KEEPALIVE: Keep-alive timeout (default: 7200s)
- APTLY_ETCD_MAX_MSG_SIZE: Max message size (default: 50MB)
3. **Retry Logic for Read Operations**
- Get operations retry up to 3 times with exponential backoff
- Only retries on temporary/network errors
- Improves reliability without risking data inconsistency
4. **Enhanced Error Logging**
- All etcd errors now logged with operation context
- Replaces silent failures with actionable error messages
- Improves debugging and monitoring capabilities
5. **Increased Message Size Limits**
- Default increased from 10MB to 50MB
- Configurable via environment variable
- Prevents "message too large" errors for large operations
## Testing
- Added comprehensive tests for etcd timeout functionality
- Tests verify context timeout, retry logic, and configuration
- All existing tests pass with the new implementation
## Documentation
- Updated README.rst with etcd configuration section
- Documented all environment variables and their defaults
- Added examples and feature descriptions
These changes significantly improve the reliability and debuggability of aptly
when using etcd as the database backend, while also fixing critical race
conditions that could cause data corruption or service crashes.
This commit addresses critical race conditions that were causing "map write failed"
errors and pod crashes in production environments. The issue occurred when multiple
goroutines accessed shared configuration maps simultaneously without proper synchronization.
Root Cause:
The global utils.Config structure contains several maps (FileSystemPublishRoots,
S3PublishRoots, SwiftPublishRoots, AzurePublishRoots) that were being accessed
directly by concurrent HTTP handlers. While context.Config() uses a mutex, it
returns a pointer to the global config, leaving subsequent map access unprotected.
Changes Made:
1. Added safe accessor methods in utils/config.go:
- GetFileSystemPublishRoots() - returns defensive copy of map
- GetS3PublishRoots() - returns defensive copy of map
- GetSwiftPublishRoots() - returns defensive copy of map
- GetAzurePublishRoots() - returns defensive copy of map
2. Updated API handlers to use safe accessors:
- api/s3.go: apiS3List() now uses GetS3PublishRoots()
- api/router.go: reposListInAPIMode() now uses GetFileSystemPublishRoots()
3. Updated context package storage initialization:
- context/context.go: GetPublishedStorage() now uses safe accessors for all
storage type configurations (filesystem, s3, swift, azure)
Impact:
- Eliminates "concurrent map writes" panics that were causing service instability
- Prevents pod crashes and restarts in Kubernetes environments
- Ensures thread-safe access to configuration maps during concurrent API requests
- Minimal performance overhead (microseconds) from creating map copies
The fix is backward compatible and requires no configuration changes. The defensive
copying approach ensures that even if config maps are modified after initialization
(which shouldn't happen in production), concurrent readers remain safe.
This addresses the production issues observed in lf-aptly-* pods where multiple
parallel publish requests or API calls were triggering race conditions.
Nick Bozhenko
André Roth
iofq
Gordian Schoenherr
Mauro Regli
Christoph Fiehe