Testkube 2.6.3
This patch release includes critical fixes for webhook event handling, addressing race conditions and duplicate event processing.
🐛 Bug Fixes
-
Webhook Event Race Condition with Multiple Listeners and Become Events (#7056)
Fixed a critical race condition that occurred when multiple webhook listeners were configured with different event type filters.
Root Cause:
- The event emitter in shared event type pointers across concurrent goroutines
- When multiple webhooks matched different event types (e.g., webhook A listens to , webhook B listens to ), the goroutines racing to filter event types would overwrite each other's field values
- This caused webhooks to receive incorrect event types or miss events entirely
Solution:
- Modified event emission to create independent copies of events for each webhook listener
- Each goroutine now gets its own event instance with correctly filtered event types
- Fixed event type filtering to use value copies instead of slice element references
- Added comprehensive test coverage for concurrent webhook scenarios:
- Single webhook with multiple event types
- Multiple webhooks with overlapping event types
- Three webhooks with different event type patterns
Technical Details:
- Shallow copy of the event is safe because only the field (a per-goroutine event type pointer) is modified
- Event type filtering now uses per-goroutine pointers instead of shared slice element references, avoiding pointer aliasing
- Enhanced dummy listener implementation for better test coverage
Impact:
- Prevents webhooks from receiving incorrect event types
- Ensures reliable event delivery in multi-webhook configurations
- Improves event routing accuracy for complex webhook setups
-
Event Idempotency Using TTL Cache (#7052)
Implemented event deduplication to prevent duplicate webhook notifications and processing of the same event multiple times.
Root Cause:
- Events could be redelivered or replayed due to various reasons (network issues, message bus redelivery/retries, system restarts)
- The event emitter had no mechanism to track which events had already been processed
- This resulted in duplicate webhook calls and duplicate event processing
Solution:
- Added TTL-based cache for tracking processed events using as the key
- Cache uses configurable capacity (default: 100,000 events) and TTL (default: 1 hour)
- Implemented atomic operation for idempotency checking:
- First encounter of an event ID stores it in cache and processes the event
- Subsequent encounters within TTL window skip processing
- Cache lifecycle managed in the method:
- Started when emitter begins listening
- Stopped when emitter is shut down
Technical Details:
- Added dependency for efficient TTL cache
- Cache capacity passed as parameter to constructor for configurability
- Event idempotency check happens before event dispatch to listeners
- Comprehensive test coverage including:
- Duplicate event detection within TTL
- Cache initialization and cleanup
Configuration:
- Default TTL: 1 hour (sufficient for most retry scenarios)
- Default capacity: 100,000 events (handles high-throughput environments)
- Both values configurable through constructor parameters
Impact:
- Eliminates duplicate webhook notifications
- Prevents redundant processing of the same events
- Improves system reliability and efficiency
- Reduces noise in webhook endpoints and logs
📝 Changelog
Bug Fixes
- 238b766: fix: webhook event race condition with multiple listeners and become events (#7056) (@Copilot, @vsukhin)
- 0e225e4: fix: add event idempotency using TTL cache on event.Id with configurable TTL and capacity (#7052) (@Copilot, @vsukhin)
Other Changes
Commits
- 58aa160: chore: release 2.6.3
Full Changelog: 2.6.2...2.6.3