mirror of
https://github.com/moltbot/moltbot.git
synced 2026-05-07 07:58:36 +00:00
977a4b24af
* fix: propagate timeoutMs to guarded dispatchers Thread timeoutMs through the dispatcher creation chain so that per-request (guarded) dispatchers honor the configured LLM timeout instead of falling back to undici's hardcoded 60s bodyTimeout/headersTimeout. Changes: - undici-runtime.ts: createHttp1Agent/ProxyAgent/EnvHttpProxyAgent now accept timeoutMs and apply bodyTimeout/headersTimeout to dispatcher options - ssrf.ts: createPinnedDispatcher accepts timeoutMs and passes it through - fetch-guard.ts: fetchWithSsrFGuard reads timeout from params or falls back to global dispatcher bodyTimeout via getGlobalDispatcher() - provider-transport-fetch.ts: buildGuardedModelFetch accepts optional timeoutMs and passes it to fetchWithSsrFGuard The global dispatcher timeout (set by ensureGlobalUndiciStreamTimeouts) is still applied to non-guarded requests. Guarded requests (used by LLM transports) now also receive the timeout via a fallback to the global dispatcher when not explicitly provided. Fixes #70829 * fix: resolve fallback timeout via module-level bridge variable Replace dead-code .options.bodyTimeout read in resolveDispatcherTimeoutMs with a module-level bridge (_globalUndiciStreamTimeoutMs) set by ensureGlobalUndiciStreamTimeouts. This avoids reliance on Undici's non-public .options field and ensures guarded dispatchers inherit the configured stream timeout instead of falling back to undici's 60s default. Fixes Greptile P1 and Codex comments on PR #70831 * chore: re-run CI smoke tests * test: cover guarded dispatcher timeout propagation * test: align timeout bridge expectation * docs: note guarded dispatcher timeout fix --------- Co-authored-by: Peter Steinberger <steipete@gmail.com>