Playwright backend: chat requests timeout for 3.5-flash / 3.1-pro / 3.1-flash-lite (HTTP 504 after ~17s)

[Skrblik]

---

name: webai-issue-body
description: Markdown body for GitHub issue about Playwright 3.5-flash timeout bug
type: text/markdown

Summary

Playwright backend chat requests against playwright/gemini/gemini-3.5-flash, playwright/gemini/gemini-3.1-pro, and playwright/gemini/gemini-3.1-flash-lite consistently return HTTP 504 "Request timed out" after roughly 17 seconds, even though /v1/auth/status reports playwright: VALID_SESSION and BrowserEngine: Initializing Browser... is logged. The webapi backend (gemini-3-flash, gemini-3-pro, gemini-3-flash-thinking, …) works flawlessly.

Environment

• WebAI-to-API: commit f81aa12 (master, 2026-06-23)
• Server: python src/run.py --host 127.0.0.1 --port 6969
• Python: 3.11.9 on Windows 11
• Auth: browser login via verify_login.py, persisted to runtime/auth/gemini.json
• Auth status:

  gemini_webapi: AUTHENTICATED  (auth_source: gemini.json canonical store)
  playwright:    VALID_SESSION  (auth_state_file: runtime/auth\gemini.json)
  

Steps to reproduce

1. python src/run.py --host 127.0.0.1 --port 6969
2. Send a chat completion request using any Playwright-prefixed model:

   curl -X POST http://127.0.0.1:6969/v1/chat/completions \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer test" \
     -d '{"model":"playwright/gemini/gemini-3.5-flash","messages":[{"role":"user","content":"hi"}],"max_tokens":50}'

3. Observe the server logs.

Actual behavior

• Server returns HTTP 504 with body {"detail":"Request timed out."} after ~17 seconds.
• Server log shows:

  AuthSelector: Source selected: gemini.json canonical store
  BrowserEngine: Initializing Browser...
  BrowserEngine: New generation active.
  ProviderSession(gemini): Closing session resources...   <-- immediately closes
  ProviderSession(gemini): All tabs purged from registry
  ProviderSession(gemini): Session resources closed successfully.
  AuthSelector: Source selected: gemini.json canonical store
  AuthSelector: Using candidate for Playwright storage: gemini.json canonical store
  INFO - provider_session_initialized
  -- then nothing for ~17s, then 504 --
  

• process_total_request_timeout is set to 120 in config.conf, so the 17-second cutoff is NOT coming from total_request_timeout. It appears to come from ui_wait_timeout = 15000 (15s) or the FastAPI/uvicorn middleware.

Expected behavior

Playwright chat requests should complete in 10-45 seconds and return a valid chat.completion JSON, like the webapi backend does.

Notes

• The /v1/models endpoint correctly advertises playwright/gemini/gemini-3.5-flash, playwright/gemini/gemini-3.1-pro, and playwright/gemini/gemini-3.1-flash-lite (added by PR Harden and synchronize Gemini Playwright model selection and discovery #93).
• src/app/services/browser/adapters/scripts/gemini_scripts.py has MODEL_PICKER_FALLBACK_SELECTORS populated (PR Harden and synchronize Gemini Playwright model selection and discovery #93) and ui_wait_timeout is documented (PR Refactor configuration routing and fix Playwright interaction timeout #85).
• Manual browser inspection of gemini.google.com shows that gemini-3.5-flash and gemini-3.1-pro exist in the UI's model picker — but Playwright's MODEL_PICKER_FALLBACK_SELECTORS (button[aria-label*="Open mode picker"], button[aria-label*="Select model"], etc.) may not match the current Gemini UI DOM, leading to a selector miss and silent timeout.
• Five chrome.exe processes start (normal for Playwright headless Chromium), so the browser is launching — but the request handler never reports back.

Suggested next steps

1. Increase ui_wait_timeout to 30000+ to rule out race conditions during UI discovery.
2. Add verbose logging around the model picker selection step so we can see which selector matched (or none).
3. Run tools/audit_ui.py against the current production gemini.google.com to refresh MODEL_PICKER_FALLBACK_SELECTORS.

[Skrblik]

Quick aside while we're at it — can you clarify what gemini-3-flash-plus vs gemini-3-flash-advanced do?

I peeked at gemini_webapi/constants.py (line 95+) and noticed something curious:

• gemini-3-flash (basic) → model_id fbb127bbb056c959, capacity_tail 1
• gemini-3-flash-thinking (basic) → model_id 5bf011840784117a, capacity_tail 1
• gemini-3-pro (basic) → model_id 9d8ca3786ebdfbea, capacity_tail 1
• gemini-3-flash-advanced → model_id 56fdd199312815e2, capacity_tail 2
• gemini-3-pro-advanced → model_id e6fa609c3fa255c0, capacity_tail 2
• gemini-3-flash-thinking-advanced → model_id e051ce1aa80aa576, capacity_tail 2
• gemini-3-flash-plus → model_id 56fdd199312815e2, capacity_tail 4 ← same as flash-advanced!
• gemini-3-pro-plus → model_id e6fa609c3fa255c0, capacity_tail 4 ← same as pro-advanced!
• gemini-3-flash-thinking-plus → model_id e051ce1aa80aa576, capacity_tail 4 ← same as thinking-advanced!

So -plus and -advanced variants share the exact same internal model_id as each other; the only difference is capacity_tail (2 vs 4). I assume capacity_tail controls reasoning effort / thinking depth, but the docs (docs/configuration.md and docs/api.md) don't say anything about these model variants — only docs/api.md mentions that the /v1/models list is "registry-driven at runtime".

Could you add a short table to docs/configuration.md mapping these model names to (a) the underlying Google model and (b) what capacity_tail does? Something like:

Model name	Underlying model	Reasoning level	Requires premium?
gemini-3-flash	Gemini 3 Flash	basic (1)	no
gemini-3-flash-thinking	Gemini 3 Flash Thinking	basic (1)	no
gemini-3-flash-advanced	Gemini 3 Flash	medium (2)	yes
gemini-3-flash-plus	Gemini 3 Flash	high (4)	yes
...

Would save users (especially those wiring this up to clients like Hermes, which shows the full list in its picker) a lot of guesswork. 🙏