Issue Station
Sign In
Tools hereToolbox

gemini-cli - ✅(Solved) Fix bug: fetchJson allows unbounded redirects due to post-increment operator [3 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#24893•Fetched 2026-04-09 08:17:47
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
0
Author
KevinZhaoKevinZhao
Participants
gemini-cli[bot]gemini-cli[bot]KevinZhaoKevinZhao
Timeline (top)
cross-referenced ×3labeled ×3commented ×1

Root Cause

fetchJson follows redirects indefinitely because the counter is never incremented in the recursive call.

Fix Action

Fixed

PR fix notes

PR #24881: fix: correct redirect count increment in fetchJson

Description (problem / solution / changelog)

Fixes #24893

Summary

fetchJson in github_fetch.ts uses post-increment (redirectCount++) when passing the redirect count to the recursive call. Post-increment evaluates to the current value before incrementing, so every recursive call receives the original value (0). This means the redirect limit check (redirectCount >= 10) on line 28 never triggers, allowing unbounded redirects.

The sibling function downloadFile in github.ts:546 correctly uses redirectCount + 1.

Changes

  • Replace redirectCount++ with redirectCount + 1 in fetchJson recursive call (one-line change)

Changed files

  • packages/cli/src/config/extensions/github_fetch.ts (modified, +1/-1)

PR #24896: fix: correct redirect count increment in fetchJson

Description (problem / solution / changelog)

Fixes #24893

Summary

fetchJson in github_fetch.ts had three issues in its redirect handling:

  1. Unbounded redirects: Used post-increment (redirectCount++) which always passes 0 to the recursive call, so the redirect limit never triggers
  2. Relative redirect URLs: Passed res.headers.location directly without resolving against the current URL — relative Location headers would fail
  3. Socket leak: The redirect response stream was not consumed, which can cause socket exhaustion

The sibling function downloadFile in github.ts:546 already handles the redirect count correctly with redirectCount + 1.

Changes

  • Replace redirectCount++ with redirectCount + 1 to correctly enforce the redirect limit
  • Use new URL(res.headers.location, url).toString() to resolve relative Location headers
  • Add res.resume() to drain the redirect response body and release the socket

Changed files

  • packages/cli/src/config/extensions/github_fetch.ts (modified, +5/-1)

PR #24911: fix: correct post-increment in fetchJson redirect counter

Description (problem / solution / changelog)

Problem

fetchJson in packages/cli/src/config/extensions/github_fetch.ts uses post-increment (redirectCount++) when passing the counter to the recursive call on line 34. Post-increment evaluates to the current value before incrementing, so every recursive call receives redirectCount = 0. The guard if (redirectCount >= 10) always evaluates 0 >= 10 → false, meaning the "Too many redirects" error is unreachable. A server returning redirect loops causes infinite recursion until a Node.js stack overflow crash.

Fixes #21007 (also reported as #24893)

Root cause

// Before — post-increment: recursive call always receives 0
fetchJson<T>(res.headers.location, redirectCount++)

// After — arithmetic: recursive call receives 1, 2, 3, ... 10
fetchJson<T>(res.headers.location, redirectCount + 1)

The sibling downloadFile function in github.ts already uses redirectCount + 1 — this fix brings fetchJson in line with the established pattern.

Changes

  • packages/cli/src/config/extensions/github_fetch.ts: one-character fix (redirectCount++ → redirectCount + 1)
  • packages/cli/src/config/extensions/github_fetch.test.ts: regression test — verifies that 11 consecutive 302 redirects result in "Too many redirects" rejection

Testing

All 9 tests pass, including the new redirect-limit test.

Changed files

  • packages/cli/src/config/extensions/github_fetch.test.ts (modified, +54/-0)
  • packages/cli/src/config/extensions/github_fetch.ts (modified, +9/-2)
RAW_BUFFERClick to expand / collapse

fetchJson in packages/cli/src/config/extensions/github_fetch.ts uses post-increment (redirectCount++) when passing the redirect count to the recursive call. Post-increment evaluates to the current value before incrementing, so every recursive call receives the original value (0). This means the redirect limit check (redirectCount >= 10) on line 28 never triggers, allowing unbounded redirects.

The sibling function downloadFile in github.ts:546 correctly uses redirectCount + 1.

Steps to reproduce

  1. Set up a server that returns infinite 301/302 redirects
  2. Call fetchJson with that URL
  3. Observe that the function follows redirects indefinitely instead of stopping at 10

Expected behavior

fetchJson should stop following redirects after 10 hops, consistent with downloadFile.

Actual behavior

fetchJson follows redirects indefinitely because the counter is never incremented in the recursive call.

extent analysis

TL;DR

Change the redirectCount++ in github_fetch.ts to redirectCount + 1 to correctly increment the redirect count in recursive calls.

Guidance

  • Identify the line in github_fetch.ts where redirectCount is passed to the recursive call and update it to use redirectCount + 1 instead of redirectCount++.
  • Verify the fix by setting up a test server with more than 10 redirects and checking that fetchJson stops following redirects after 10 hops.
  • Compare the implementation of fetchJson with downloadFile in github.ts to ensure consistency in handling redirect counts.
  • Test the updated fetchJson function with different redirect scenarios to ensure it behaves as expected.

Example

// Before
fetchJson(url, options, redirectCount++);

// After
fetchJson(url, options, redirectCount + 1);

Notes

This fix assumes that the intention is to increment the redirectCount variable before passing it to the recursive call, similar to the implementation in downloadFile.

Recommendation

Apply the workaround by changing redirectCount++ to redirectCount + 1 to ensure the redirect count is correctly incremented and the function stops following redirects after 10 hops.

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…

FAQ

Expected behavior

fetchJson should stop following redirects after 10 hops, consistent with downloadFile.

#environment setup#docker error#permission error#memory optimization#batch processing

Still need to ship something?

×6

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

Back to top recommendations

TRENDING