Skip to content

fix(gateway): isolate platform connect failures with per-platform timeout (#17242) - #17429

Merged
teknium1 merged 2 commits into
mainfrom
hermes/hermes-bfbd0710
Apr 29, 2026
Merged

fix(gateway): isolate platform connect failures with per-platform timeout (#17242)#17429
teknium1 merged 2 commits into
mainfrom
hermes/hermes-bfbd0710

Conversation

@teknium1

Copy link
Copy Markdown
Contributor

Salvage of #17270 by @tmimmanuel.

One platform's slow/hanging adapter.connect() no longer blocks initialization of the others. Telegram's 8-retry connect loop (~140s worst case in network-restricted regions like China) previously prevented Feishu/Lark from ever starting when Telegram was unreachable — users had to comment Telegram out to get any other platform working.

How

Wrap each adapter.connect() call in asyncio.wait_for() via a new helper, _connect_adapter_with_timeout(). Used at both the startup loop and the reconnect watcher, so a platform that stalls mid-retry also does not stall retries for the others. On timeout the platform is queued for background reconnection like any other transient failure.

  • Default timeout: 30s
  • Override: HERMES_GATEWAY_PLATFORM_CONNECT_TIMEOUT env var
  • Disable: set to 0
  • Invalid values log a warning and fall back to the default

Changes

  • gateway/run.py: add _platform_connect_timeout_secs() + _connect_adapter_with_timeout(); route both startup and reconnect through it.
  • tests/gateway/test_platform_reconnect.py: two new tests — one proving startup continues past a Telegram timeout and still connects Feishu, one proving the helper raises TimeoutError on hang.
  • scripts/release.py: AUTHOR_MAP entry for tmimmanuel.

Validation

  • scripts/run_tests.sh tests/gateway/test_platform_reconnect.py → 16/16 passed
  • E2E with a HangAdapter:
    • HERMES_GATEWAY_PLATFORM_CONNECT_TIMEOUT=0.2 → bounded at 0.2s, raises TimeoutError
    • HERMES_GATEWAY_PLATFORM_CONNECT_TIMEOUT=0 → timeout disabled, connect runs unbounded
    • Fast-connecting adapter returns True under any positive timeout

Salvage notes

Cherry-picked tmimmanuel's gateway/run.py + tests/gateway/test_platform_reconnect.py changes onto current main. Dropped an unrelated cron/scheduler.py portion that was a rebase artifact from their earlier #17139 branch. Also closes #17383 by @vominh1919, which proposed the same timeout approach without tests and only on the startup path (missing the reconnect-watcher site).

Closes #17242

tmimmanuel and others added 2 commits April 29, 2026 05:00
…eout

Wrap each adapter.connect() in asyncio.wait_for() so one platform hanging
during startup or reconnect cannot block the others. Telegram's 8-retry
connect loop (~140s worst case) previously prevented Feishu from ever
starting when Telegram was network-restricted — common for users in
regions where Telegram is blocked.

Default timeout is 30s; override via HERMES_GATEWAY_PLATFORM_CONNECT_TIMEOUT
(0 disables). Applied to both startup and the reconnect watcher so a
platform that hangs mid-retry also does not stall retries for others.

Fixes #17242
@teknium1
teknium1 force-pushed the hermes/hermes-bfbd0710 branch from 188208f to 667d2e3 Compare April 29, 2026 12:00
@teknium1
teknium1 merged commit 4643796 into main Apr 29, 2026
4 checks passed
@teknium1
teknium1 deleted the hermes/hermes-bfbd0710 branch April 29, 2026 12:00
@alt-glitch alt-glitch added type/bug Something isn't working P2 Medium — degraded but workaround exists comp/gateway Gateway runner, session dispatch, delivery labels Apr 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/gateway Gateway runner, session dispatch, delivery P2 Medium — degraded but workaround exists type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] Platform initialization failure blocks other platforms (Telegram blocks Feishu)

3 participants