zeroclaw/src/providers
Edvard cc13fec16d fix: add provider warmup to prevent cold-start timeout on first channel message
The first API request after daemon startup consistently timed out (120s)
when using channels (Telegram, Discord, etc.), requiring a retry before
succeeding. This happened because the reqwest HTTP client's connection
pool was cold — no TLS handshake, DNS resolution, or HTTP/2 negotiation
had occurred yet.

The fix adds a `warmup()` method to the Provider trait that establishes
the connection pool on startup by hitting a lightweight endpoint
(`/api/v1/auth/key` for OpenRouter). The channel server calls this
immediately after creating the provider, before entering the message
processing loop.

Tested on Raspberry Pi 5 (aarch64) with OpenRouter + DeepSeek v3.2 via
Telegram channel. Before: first message took 2-7 minutes (120s timeout +
retries). After: first message responds in <30s with no retries.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-14 18:43:26 -05:00
..
anthropic.rs hardening: fix 7 production weaknesses found in codebase scan 2026-02-14 01:47:08 -05:00
compatible.rs hardening: fix 7 production weaknesses found in codebase scan 2026-02-14 01:47:08 -05:00
mod.rs feat: enhance agent personality, tool guidance, and memory hygiene 2026-02-14 11:28:39 -05:00
ollama.rs hardening: fix 7 production weaknesses found in codebase scan 2026-02-14 01:47:08 -05:00
openai.rs hardening: fix 7 production weaknesses found in codebase scan 2026-02-14 01:47:08 -05:00
openrouter.rs fix: add provider warmup to prevent cold-start timeout on first channel message 2026-02-14 18:43:26 -05:00
reliable.rs fix: add provider warmup to prevent cold-start timeout on first channel message 2026-02-14 18:43:26 -05:00
traits.rs fix: add provider warmup to prevent cold-start timeout on first channel message 2026-02-14 18:43:26 -05:00