fix(nodes): retry Gmail rate-limit 403s instead of failing fast (#1560)#1571
fix(nodes): retry Gmail rate-limit 403s instead of failing fast (#1560)#1571meetp06 wants to merge 1 commit into
Conversation
…etride-org#1560) gmail_client.execute() retried 429/5xx but failed fast on every 403, including transient rate-limit/quota 403s that Gmail returns (userRateLimitExceeded / rateLimitExceeded / quotaExceeded). Those are retryable and should not surface as a hard error. Add `_is_rate_limit_403()` which inspects the structured error body (error.status / error.errors[].reason) and treats only rate-limit/quota reasons as retryable, and include such 403s in the execute() retry path alongside the existing transient statuses. Scope/permission 403s still fail fast with the reconnect message. Any parse failure conservatively treats the 403 as non-retryable. Tests: reason detection (all three rate-limit reasons + scope/garbage rejection), a rate-limit 403 retried then succeeding, and a scope 403 failing without retry. Full tool_gmail suite passes (90 tests). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
🤖 Internal: Discord sync markerAuto-managed by the Discord notification workflow. Stores the linked Discord message ID and forum thread ID. Do not edit or delete. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughGmail request retries now recognize structured 403 rate-limit and quota errors while preserving immediate failure for permission and scope errors. Unit tests cover response parsing, retry-to-success behavior, and fail-fast handling. ChangesGmail retry handling
Estimated code review effort: 3 (Moderate) | ~20 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Addresses #1560 (the 403 rate-limit retry item — see Scope).
Problem
gmail_client.execute()retries transient429/5xxstatuses but fails fast on every403. Gmail returns rate-limit/quota conditions as403with a structured reason (userRateLimitExceeded,rateLimitExceeded,quotaExceeded) — those are transient and retryable, but currently surface as a hard error mid-run.Fix
_is_rate_limit_403(exc)which parses the structured error body (error.status/error.errors[].reason) and returns True only for rate-limit/quota reasons. Any parse failure conservatively returns False (non-retryable).execute()retry path alongside the existing transient statuses. Scope/permission 403s still fail fast with the reconnect message.Tests
_is_rate_limit_403: detects all three rate-limit reasons; rejects a scope reason, non-JSON, and empty body.execute(): a rate-limit 403 is retried and then succeeds; a scope 403 fails immediately with no retry._time.sleepis patched so the backoff doesn't slow the suite.Verification (run locally)
Scope
This is the 403 rate-limit retry item of #1560. The credential-hardening items (token_uri validation, broker-refresh reliability, schemeless broker URL) are handled in #1569; the protobuf floor bump and the
nodes/core/client hoist remain as separate follow-up.🤖 Generated with Claude Code
Summary by CodeRabbit