Fixed
Telegram long-poll timeout spam (#6)
Long-poll timeouts during getUpdates are an expected, normal occurrence on flaky networks — they just mean "no new messages within the long-poll window, try again". Previously they were logged as Telegram API error: The read operation timed out and could spam logs heavily on weak connections (raised in #6 by @hypnosis4u2nv).
Now:
- Long-poll timeouts are silent
- Real errors (HTTP 4xx/5xx, connection refused, JSON parse failures) are still logged
- Other Telegram API methods (
sendMessage,answerCallbackQuery, etc.) still log their timeouts since those carry real meaning
Long-poll vs HTTP-timeout balance
The previous setup (30s long-poll, 60s HTTP socket) was knife-edge on slow networks: a slow TLS handshake could trip the HTTP timeout before Telegram returned. Re-tuned:
- Long-poll window: 30s → 25s
- HTTP socket timeout: now
25 + 15 = 40s— explicit 15s buffer - Faster reaction to genuinely dead connections; more headroom for slow handshakes
send_message retry
The "retry without Markdown" path now only triggers when Telegram actively rejected the message (ok=false, typically a parse error). Network-level failures aren't retried — repeating a request that just timed out doesn't help.
Upgrade
docker pull amayer1983/docksentry:latest
docker compose up -dNo configuration changes required.