chrome_timeout_ms设置无效

[ID95613]

2026-05-09T07:45:39.443559Z  INFO crw_server: Starting CRW on 0.0.0.0:3000

2026-05-09T07:45:39.443567Z  INFO crw_server: Renderer mode: Auto

2026-05-09T07:45:39.443569Z  INFO crw_server: Renderer render_js_default: None

2026-05-09T07:45:39.443573Z  INFO crw_server: Lightpanda CDP: ws://lightpanda:9222/

2026-05-09T07:45:39.443574Z  INFO crw_server: Chrome CDP: ws://172.21.100.100:9222/

2026-05-09T07:45:39.443576Z  INFO crw_server: LLM structured extraction: enabled

2026-05-09T07:45:39.450201Z  INFO crw_server: JS renderers in fallback order: ["lightpanda", "chrome"]

2026-05-09T07:45:39.450282Z  INFO crw_server: CRW ready at http://0.0.0.0:3000

2026-05-09T07:46:17.970678Z  INFO crw_renderer: SPA shell detected, retrying with JS renderer url="https://x.com/trq212/status/2033949937936085378"

2026-05-09T07:46:21.319582Z  WARN crw_renderer: JS renderer failed: Timeout after 2500ms renderer="lightpanda"

2026-05-09T07:46:21.320451Z  INFO crw_renderer::cdp: Discovering browser WS URL from http://172.21.100.100:9222/json/version renderer="chrome"

2026-05-09T07:46:21.326580Z  INFO crw_renderer::cdp: Discovered browser WS URL renderer="chrome" ws_url=ws://172.21.100.100:9222/devtools/browser/4645ba3c-e30d-480c-9555-709dba3b27e0

2026-05-09T07:46:24.092012Z  WARN crw_renderer: JS renderer failed: Timeout after 2771ms renderer="chrome"

2026-05-09T07:46:24.092062Z  WARN crw_renderer: JS rendering failed, falling back to HTTP result: Timeout after 2771ms

lightpanda_timeout_ms = 2500
chrome_timeout_ms = 30000

[us]

Fixed in #38, deployed to fastcrw.com.

Root cause. The CDP fetch path runs min(internal_timeout, deadline.remaining()) to keep renders inside the end-to-end deadline. The default deadline_ms_default = 8000 was small enough that any renderer's full per-tier budget got crushed against the remaining deadline, so chrome_timeout_ms = 30000 (and lightpanda_timeout_ms = 2500) silently capped at whatever was left after lightpanda already burned 2.5–3s.

Fix. New config knob request.auto_extend_deadline_for_ladder (default true). When a request omits deadlineMs, the effective deadline is widened to max(deadline_ms_default, sum(http+lightpanda+chrome timeouts) + N_cdp_tiers × 28s). Explicit per-request deadlineMs always wins. Tower outer timeout is sized off the same envelope so middleware can't cancel a healthy handler.

Verification on production engine just now:

$ time curl -X POST http://localhost:3000/v1/scrape \
    -d '{"url":"https://x.com/trq212/status/2033949937936085378",
         "formats":["markdown"],"renderJs":true}'
{"success":true, ... "renderedWith":"lightpanda","elapsedMs":1837}
real  0m4.689s

Real content rendered, no Timeout after 2771ms. Startup log now shows:

ladder_min_ms=92500  effective_default_ms=92500
outer_timeout_secs_baseline=120  outer_timeout_secs_effective=413

Your 30s chrome_timeout_ms will now run to completion when chrome is selected. If you want the strict 8s SLO behavior back, set request.auto_extend_deadline_for_ladder = false in config.docker.toml.

Thanks for the detailed log trace — it made the diagnosis straightforward.