fix(gateway): give Feishu a 90s first-connect budget

[686f6c61]

What breaks

After hermes update, Feishu often comes up as:

feishu connect timed out after 30s
Gateway started with no connected platforms

A later in-process retry connects in ~1s. If the updater restarts the gateway process before that retry, there is no cache and the bot stays offline until someone restarts it by hand. Users see “Feishu stopped after update”.

Why

Two stacked changes:

1. Per-platform connect isolation defaults to 30s. Only Telegram gets 180s (real getUpdates on first connect).
2. lark_oapi was deferred into connect() via asyncio.to_thread(_load_lark_oapi) so an unused Feishu extra does not pay ~24s at import. The SDK is ~49MB / 10k+ modules. Measured cold import on the reporter’s box: 24.3s. Import + websocket handshake > 30s every cold boot.

Once the module is in sys.modules, retry is ~1s. The 30s bound is only fatal on the first connect of a fresh process — exactly the post-update path.

gateway.platform_connect_timeout: 60 already unblocks this (reporter: first connect at 33s). There was no Feishu-specific default.

What this changes

GatewayRunner._platform_connect_timeout_secs(Platform.FEISHU) is 90s, same idea as Telegram’s extra budget.

HERMES_GATEWAY_PLATFORM_CONNECT_TIMEOUT and gateway.platform_connect_timeout still win over that default. If you already set 60 as the #19776 escape hatch, first connect stays capped at 60s after this lands — drop the override to get the 90s budget. Reporter follow-up: Windows 11 / lark-oapi 1.6.8 cold connect ~33s with that 60s cap.

The lazy import is left in place: we do not pull lark_oapi back to module scope (that was #57657 / #68756).

Verify

pytest tests/gateway/test_feishu_lazy_import.py::test_feishu_connect_timeout_exceeds_cold_sdk_import
# 1 passed

Existing lazy-import tests still assert the SDK is not loaded at config time. Not re-timed against a real Feishu tenant on this machine.

Fixes #85564

[ccctakexx]

Thanks — this matches my report exactly, and it fixes the issue for me.

Concrete data point: on my machine (Windows 11, lark-oapi 1.6.8) the cold connect with gateway.platform_connect_timeout: 60 completes in ~33s (24s import + WS handshake), so a 90s default has ~3x headroom. The in-process retry self-recovery also matches what I see in gateway.log.

One note for the release notes: users who already set gateway.platform_connect_timeout (the #19776 escape hatch, e.g. to 60) will still be capped by their explicit value — it wins over the per-platform default. Worth mentioning so people can drop the override after upgrading to get the 90s budget.

[686f6c61]

Thanks for the timing on Windows — 33s cold with a 60s cap matches the original report.

Confirmed the precedence: HERMES_GATEWAY_PLATFORM_CONNECT_TIMEOUT / gateway.platform_connect_timeout return before the Feishu 90s default, so a leftover 60 still caps first connect. Called that out in the PR body so it can land in the notes. After this merges, drop the override unless you still want a global cap.

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

fix(gateway): give Feishu a 90s first-connect budget

1. The 90s budget only applies when the user has no explicit gateway.platform_connect_timeout override — users who set the Discord gateway connect timeout is too short when slash command sync takes >30s #19776 escape hatch (e.g. to 60s) to cope with slow connects will not get the 90s and may still hit the timeout (the PR's own thread already notes this for release notes; consider also documenting it in the config defaults). Since those users are likely the exact population that hit Desktop startup blocked ~11s on /api/status: eager plugin resolution imports lark_oapi (10,055 modules) on the event loop #68756, this gap is worth a deliberate decision rather than a footnote.

2. tests/gateway/test_feishu_lazy_import.py — the test calls _platform_connect_timeout_secs on GatewayRunner.__new__(GatewayRunner), which only works while the method resolves config from module state rather than self. It fails loudly if the method is later refactored to read self.config, so it is safe, but a module-level helper (or a real instance) would be cleaner to test.

3. 90s applies to every Feishu connect, not just the first cold one. Steady-state reconnects (warm import, fast handshake) will now wait up to 90s before failing over. The stated problem is "first boot after update"; consider extending the budget only for the first connect per process and keeping subsequent connects on the 30s bound for faster failure.

[Enough1122]

@C:/Users/admin/AppData/Local/Temp/opencode/review-85595.md