From ee962aab50c00c1405890e0fb3ea6aecd4ad889d Mon Sep 17 00:00:00 2001 From: Ace Data Cloud Dev Date: Wed, 22 Jul 2026 20:56:11 +0800 Subject: [PATCH] =?UTF-8?q?fix(channels):=20raise=20doctor=20probe=20timeo?= =?UTF-8?q?ut=205s=E2=86=9215s=20to=20avoid=20cold-TLS=20false=20ConnectTi?= =?UTF-8?q?meout?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The doctor auth probe used a 5s timeout, but a cold TLS handshake to a hosted WeChat gateway (e.g. *.wisdom.acedata.cloud) can take ~6-7s on the first connect. That made `channels doctor` report [FAIL] unreachable: ConnectTimeout even though `channels start` connects fine — a confusing false negative during first-time setup. Bump the probe timeout to 15s. Co-Authored-By: Claude Opus 4.8 (1M context) --- coding_bridge/channels_cli.py | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/coding_bridge/channels_cli.py b/coding_bridge/channels_cli.py index 04ed817..74273f4 100644 --- a/coding_bridge/channels_cli.py +++ b/coding_bridge/channels_cli.py @@ -164,7 +164,11 @@ async def _doctor_one(inst: WeChatInstanceConfig) -> tuple[bool, str]: return False, f"token: {exc}" token_len = len(token) # only the length is safe to display - client = WeChatClient(inst.base_url, token, timeout=5.0) + # 15s, not 5s: a cold TLS handshake to a hosted gateway (e.g. + # *.wisdom.acedata.cloud) can take ~6-7s on the first connect, which a + # 5s timeout would mis-report as an unreachable ConnectTimeout even though + # `channels start` connects fine. + client = WeChatClient(inst.base_url, token, timeout=15.0) try: # Probe id is a syntactically valid but almost-certainly-unknown token. # It uses only characters allowed by _TASK_ID_RE so `get_task_status`