micro--go-micro
baeb282cf1
* Initial plan * Enhance cache rate limiting to protect against rolling deployment scenarios Per @asim's feedback, rate limiting now applies to ALL cache refresh attempts (not just error cases) to prevent registry overload during rolling deployments. Changes: - Rate limit ALL refresh attempts using lastRefreshAttempt tracking - Always return stale cache if available (even if expired) when rate limiting - Only return ErrNotFound when no cache exists during rate limit period - Rate limiting happens inside singleflight to avoid race conditions - Update test to reflect new behavior (no retry when stale cache + rate limit) - Enhanced documentation with rolling deployment scenario examples This addresses the scenario where all upstream services expire their cache simultaneously during a downstream rolling deployment, which would previously cause a stampede to the registry under high QPS. Co-authored-by: asim <17530+asim@users.noreply.github.com> * Remove unused failedAttempts and consecutiveFailures fields Per @asim's feedback, these fields are no longer needed since the new rate limiting strategy uses lastRefreshAttempt to track ALL refresh attempts, not just failed ones. Removed: - failedAttempts map[string]time.Time - consecutiveFailures int - All code that sets these fields The rate limiting logic now only uses lastRefreshAttempt, making these fields redundant. All tests continue to pass. Co-authored-by: asim <17530+asim@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: asim <17530+asim@users.noreply.github.com>