LLM_TIMEOUT_MS default 60 s -> 3 min (v0.21.4)

Production incident: '#rss get lublin' at 9:41 AM failed with 'The operation was aborted due to timeout' — the LlmService call hit its 60 s cap while the local OpenAI-compatible server (qwen3.8-27b, uncontrollable reasoning tokens) was slow/busy. The same endpoint answers a trivial prompt in ~1 s when idle, so this is latency variance on the server side, not a dead endpoint. Bump the LLM_TIMEOUT_MS fallback from 60000 to 180000 (3 min headroom for slow reasoning periods); still env-overridable, only the default changed.
2026-09-26 09:52:18 +00:00
parent 0722c82359
commit 98b9ec5185
4 changed files with 8 additions and 4 deletions
@@ -1,5 +1,9 @@
 # Changelog

+## v0.21.4 — 2026-09-26 09:51
+
+- `LLM_TIMEOUT_MS` default raised from 60000 (60 s) to **180000** (3 min): production incident — `#rss get lublin` at 9:41 AM failed with "The operation was aborted due to timeout" because the local OpenAI-compatible server (qwen3.8-27b, uncontrollable reasoning tokens) was slow/busy on that call; the same endpoint answers a trivial prompt in ~1 s when idle, so this is latency variance, not a dead endpoint. Still env-overridable (`LLM_TIMEOUT_MS`), only the fallback changed.
+
 ## v0.21.3 — 2026-09-26 09:31

 - Idle timeout default lowered from 10 min to **1 min** (`MESH_IDLE_TIMEOUT_MS` fallback `600000` → `60000`) — the v0.21.2 frame-based watchdog works in production (it fired today and the reconnect delivered queued packets), but the bridge/radio side at 192.168.1.4 keeps killing inbound RX within ~20 min of a fresh sync, so a shorter detection window is wanted.