mirror of
https://github.com/turbot/steampipe.git
synced 2025-12-19 18:12:43 -05:00
4f1367fe6c
* Add test demonstrating bug #4786 - race in updateRateLimiterStatus Test demonstrates the race condition when updateRateLimiterStatus reads from the userLimiters map without holding a lock, while another goroutine concurrently writes to the map. Running with -race flag shows data races at: - plugin_manager_rate_limiters.go:176 (read in getUserDefinedLimitersForPlugin) - plugin_manager_rate_limiters.go:161 (read in updateRateLimiterStatus) - rate_limiters_test.go:40 (concurrent write) Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> * Fix #4786: Protect updateRateLimiterStatus with RWMutex Add RWMutex write lock protection to updateRateLimiterStatus to prevent race conditions when the method reads from userLimiters map and writes to pluginLimiter.Status fields while other goroutines concurrently modify these data structures. The fix uses m.mut.Lock() (not RLock) because the method modifies the pluginLimiter.Status field, requiring exclusive write access. Note: This fix assumes updateRateLimiterStatus is not called from within a context that already holds the mutex. If it is, additional refactoring will be needed to prevent deadlock. Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> * Fix deadlock in updateRateLimiterStatus The previous fix introduced a deadlock where updateRateLimiterStatus() would: 1. Acquire m.mut.Lock() 2. Call getUserDefinedLimitersForPlugin() 3. Which tries to acquire m.mut.RLock() - deadlock! Go mutexes cannot acquire RLock when the same goroutine already holds Lock. Fix by refactoring into internal/public pattern: - getUserDefinedLimitersForPlugin() - public, acquires RLock - getUserDefinedLimitersForPluginInternal() - internal, no lock (caller must hold it) - updateRateLimiterStatus() now calls internal version while holding lock Test verification: TestPluginManager_UpdateRateLimiterStatus_NoOverride - Before: Timeout after 28s - After: Pass in 0.429s Fixes #4786 --------- Co-authored-by: Claude <noreply@anthropic.com>