[Bug] gemini-web → 502 "No response from Gemini" — the 30s StreamGenerate wait always expires, and one request is retried 5× (~180s) before the client gives up

[yoursshadow50]

[Bug] gemini-web → 502 No response from Gemini — the 30s StreamGenerate wait always expires, and one request is retried 5× (~180s) before the client gives up

Category suggestion: Bug report Severity: Provider unusable — 100% of requests, every model, single account or many Short version: gemini-web types the prompt, presses Enter, then waits 30s for a response whose URL contains StreamGenerate. Nothing is ever captured, so it returns 502 {"error":"No response from Gemini"}. The retry/cooldown layer then re-runs the whole 38-second attempt five times, so a single client request occupies ~3 minutes and ends in request_signal_aborted.

---

1. Environment

Item | Value -- | -- OmniRoute image | diegosouzapw/omniroute:next-web Image published | 2026-10-07T09:56:55Z Image digest | sha256:baf25bf6c3c629c6a9b7df26ca766165fdda883fab030cfb6d7090049a190492 Release this maps to | 3.8.51 (current npm latest, published 2026-09-30) Upstream source checked | release/v3.8.52 @ 2026-10-18T16:59:51Z Host | Hugging Face Space (Docker SDK), custom Dockerfile with FROM diegosouzapw/omniroute:next-web Browser | Playwright Chromium headed under Xvfb (DISPLAY=:99, 1280x1024x24) Provider | Gemini Web (Free) (gemini-web / alias gweb) Model | gemini-3.1-pro Account | 1 connection, id 5be5d839… ("main") Client | OpenAI-compatible /v1/chat/completions from an external client

Last commit touching open-sse/executors/gemini-web.ts: 2026-10-09 (#15076). Nothing since — no fix is in the pipeline, and the newest browser image (main-web, published 2026-10-16) does not contain one either.

---

8. Suggested fix

Three separable improvements, in order of value:

(a) Make the failure diagnosable. Right now A and B are indistinguishable. Capture the response URLs seen during the window and include them in the error:

That single change turns every future report into a definite answer: "no POST at all" ⇒ send-side/UI change; "POST to X, not StreamGenerate" ⇒ endpoint moved; "POST to StreamGenerate but empty parse" ⇒ parser drift.

(b) Distinguish "no response" from "unparseable response". Don't resolve the promise into an empty string when the body read throws — set an explicit parseFailed flag and return a different message (or 502 with code: "gemini_parse_failed") so account-fallback can treat it correctly.

(c) Don't spend 5 × 38s on a terminal failure. A StreamGenerate-timeout is a DOM/endpoint mismatch, not a transient upstream fault — the same reasoning that made #9407 return 400 for selector timeouts. Returning 502 here causes the cooldown ladder to re-run the whole browser flow four more times. Either classify it as terminal (400, no cooldown retries) or cap the cooldown retries for gemini-web at 1.

Additionally, an env knob for the capture window would help users on slow links or cold Xvfb boots, e.g. GEMINI_WEB_RESPONSE_TIMEOUT_MS (default 30000). There is currently no override of any kind.

---

9. Reproduction

1. Run diegosouzapw/omniroute:next-web with headed Chromium + Xvfb (or an HF Space built FROM …:next-web).

1. Add a Gemini Web (Free) connection with a valid __Secure-1PSID + __Secure-1PSIDTS; "Check cookie" reports Valid and the connection shows Connected.

1. POST /v1/chat/completions with model gweb/gemini-3.1-pro (or gemini-3.7-flash, gemini-3.1-flash-lite).

1. Observe 502 No response from Gemini after ~13–16s, then repeated attempts at ~38s each, then request_signal_aborted when the client times out.

1. Deterministic — 100% of attempts across multiple models, no successful completion in the window 17:44–17:54.

---

10. Ask

1. Make the failure self-describing (§8a) — without it, every report about this provider is guesswork.

1. Separate "no StreamGenerate seen" from "seen but parsed empty" (§8b).

1. Treat a capture-window expiry as terminal instead of retryable, or cap the cooldown ladder (§8c).

1. Add GEMINI_WEB_RESPONSE_TIMEOUT_MS as an escape hatch.

1. Fix the attempt 4/3 counter overrun (§6).

1. Confirm whether StreamGenerate is still the endpoint the current gemini.google.com frontend uses — if it moved, that is the whole bug, and [BUG] gemini-web provider hangs on every request — stale "StreamGenerate" URL match no longer exists in Gemini's frontend #10751 has simply regressed.

Happy to test a candidate build on the Space and report back with full logs.

[diegosouzapw]

@yoursshadow50 Thank you, this is a thorough report. What I checked in the code (release/v3.8.52, open-sse/executors/gemini-web.ts): the browser flow does wait for a response whose URL contains StreamGenerate, and if the body read throws it falls through to the "No response from Gemini" 502, exactly as you describe. I did not verify the rest: that Google's frontend moved away from that endpoint, the 5× retry (~180 s) behavior, or the attempt-counter overrun. I can't test a logged-in Gemini page from here.

Your three suggestions look sensible and independent of whether the endpoint moved: (a) put the response URLs seen during the window into the error, so "no POST at all" and "POST to another URL" can be told apart; (b) separate "no response" from "unparseable response"; (c) don't retry a capture-window timeout as if it were transient. Fixes for browser-driven providers need a live check, so I'm not promising a date. There's an open issue about this provider, #16935, and an earlier similar one, #10751 (closed), which would be the first to compare with. If you can run the candidate build you offered, say so here when there is one.