Issue Station
Sign In
Tools hereToolbox

gemini-cli - ✅(Solved) Fix Rate limit bypass in web_fetch fallback path [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
google-gemini/gemini-cli#26382•Fetched 2026-05-03 04:52:18
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
Akash504-aiAkash504-ai
Participants
Akash504-aiAkash504-aigemini-cli[bot]gemini-cli[bot]
Timeline (top)
closed ×1commented ×1cross-referenced ×1labeled ×1

Error Message

throw new Error(Rate limit exceeded for ${urlStr});

Root Cause

Root cause:

Fix Action

Fixed

PR fix notes

PR #26383: fix(web-fetch): enforce rate limiting in fallback fetch execution and add tests

Description (problem / solution / changelog)

Summary

Fixes a gap where rate limiting was enforced in the primary web fetch path but not consistently respected in the fallback execution path. This could allow excessive requests to the same host when fallback logic is triggered.

This change ensures rate limiting is applied uniformly across both primary and fallback fetch flows.

Details

  • Enforced host-based rate limiting inside fallback execution (executeFallbackForUrl)
  • Ensured skipped/blocked URLs are handled consistently with primary flow
  • Added test coverage for:
    • Rate limit enforcement during fallback execution
    • Error behavior when limit is exceeded in fallback path

This keeps behavior aligned between primary and fallback fetch mechanisms and prevents unintended request bursts.

Related Issues

Fixes #26382

How to Validate

  1. Run tests: 
    npm test
  2. Verify new test:
  • should respect rate limit in fallback execution
  1. Manual validation:

  • Trigger multiple requests (>10) to same host

  • Confirm:

    -  Requests are blocked after limit
-  Proper error is returned

Changed files

  • packages/core/src/tools/web-fetch.test.ts (modified, +30/-0)
  • packages/core/src/tools/web-fetch.ts (modified, +4/-0)
RAW_BUFFERClick to expand / collapse

What happened?

The web_fetch tool applies rate limiting in the primary execution path, but the fallback path does not enforce it.

When the primary fetch fails and fallback is triggered, multiple requests to the same host are executed without any rate limiting.

This allows exceeding the intended limit (10 requests per minute per host).

What did you expect to happen?

Rate limiting should be applied consistently in both the primary and fallback execution paths.

Fallback requests should respect the same per-host rate limits as the primary fetch logic.

Client information

Not relevant for this backend bug.

Login information

Not relevant.

Anything else we need to know?

Root cause:

  • checkRateLimit() is only used in filterAndValidateUrls()
  • Fallback path (executeFallback → executeFallbackForUrl) makes network requests without checking rate limits

Flow: execute() → filterAndValidateUrls() → (primary fails) → executeFallback() → executeFallbackForUrl()

Suggested fix:

Add a rate limit check at the start of executeFallbackForUrl():

const rate = checkRateLimit(urlStr); if (!rate.allowed) { throw new Error(Rate limit exceeded for ${urlStr}); }

extent analysis

TL;DR

Add a rate limit check at the start of the executeFallbackForUrl() function to ensure consistent rate limiting in both primary and fallback execution paths.

Guidance

  • Identify the executeFallbackForUrl() function and add the suggested rate limit check using the checkRateLimit() function.
  • Verify that the checkRateLimit() function is correctly implemented and returns an object with an allowed property indicating whether the rate limit has been exceeded.
  • Test the fallback path with multiple requests to the same host to ensure that the rate limit is enforced correctly.
  • Review the filterAndValidateUrls() function to ensure that the rate limit check is correctly applied in the primary execution path.

Example

const rate = checkRateLimit(urlStr);
if (!rate.allowed) {
  throw new Error(`Rate limit exceeded for ${urlStr}`);
}

Notes

This fix assumes that the checkRateLimit() function is correctly implemented and returns accurate results. Additional testing may be necessary to ensure that the rate limit is enforced correctly in all scenarios.

Recommendation

Apply the suggested workaround by adding the rate limit check to the executeFallbackForUrl() function, as this will ensure consistent rate limiting in both primary and fallback execution paths.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#authentication setup#request error#file not found#serialization error#model compatibility

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING