From 5932ec4552bad49e00790184d6e22a55e7d54c5a Mon Sep 17 00:00:00 2001
From: rob-maron <132852777+rob-maron@users.noreply.github.com>
Date: Thu, 30 Jul 2026 17:26:40 -0400
Subject: [PATCH] more conservative to 120s

---
 plugins/platforms/telegram/adapter.py | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/plugins/platforms/telegram/adapter.py b/plugins/platforms/telegram/adapter.py
index a70cb33b10d..37f45a28f49 100644
--- a/plugins/platforms/telegram/adapter.py
+++ b/plugins/platforms/telegram/adapter.py
@@ -584,8 +584,9 @@ _POLLING_PROGRESS_TIMEOUT = 60.0
 # Telegram transcodes an uploaded video before it answers sendVideo, so the
 # wait for the response is unrelated to how fast the bytes went out and
 # routinely exceeds the 20s read timeout the rest of the Bot API is tuned for.
-# Only media sends take this longer budget.
-_MEDIA_SEND_READ_TIMEOUT = 180.0
+# Only media sends take this longer budget; ordinary calls keep the short one
+# so a dead request is still noticed quickly.
+_MEDIA_SEND_READ_TIMEOUT = 120.0
 _POLLING_GENERATION_CONTEXT: ContextVar[Optional[int]] = ContextVar(
     "telegram_polling_generation", default=None
 )
@@ -3672,9 +3673,11 @@ class TelegramAdapter(BasePlatformAdapter):
                 # Not a duplicate of write_timeout: PTB routes any request
                 # carrying files to media_write_timeout instead, so the line
                 # above never applied to an upload and every upload was pinned
-                # to PTB's own 20s default.
+                # to PTB's own 20s default. 120s covers a 50MB video on a
+                # ~4Mbps uplink; going higher only lengthens how long a dead
+                # socket takes to report itself.
                 "media_write_timeout": _env_float(
-                    "HERMES_TELEGRAM_HTTP_MEDIA_WRITE_TIMEOUT", 300.0
+                    "HERMES_TELEGRAM_HTTP_MEDIA_WRITE_TIMEOUT", 120.0
                 ),
             }