fix(update): increase npm registry fetch timeout from 5s to 15s - #1724
Conversation
The update checker fetches https://registry.npmjs.org/@larksuite/cli/latest with a 5-second HTTP client timeout. Under high-latency network conditions (TUN-mode proxies, VPNs, transcontinental routes), TLS handshake alone can take 4-6 seconds, causing the check to fail with: context deadline exceeded (Client.Timeout exceeded while awaiting headers) Measured example behind a Clash TUN proxy (US node from China): DNS resolve: ~0ms (fake-ip) TCP connect: ~0ms (local TUN) TLS handshake: 4.3-5.9s <-- bottleneck Total: 4.7-6.3s curl succeeds because it has no default connect timeout, but the Go HTTP client with Timeout=5s is too tight. The registry endpoint returns a tiny JSON payload (<1KB), so 15s is more than enough headroom while still failing fast on genuinely unreachable networks.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe ChangesTimeout Configuration Update
Estimated code review effort: 1 (Trivial) | ~2 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🚀 PR Preview Install Guide🧰 CLI updatenpm i -g https://pkg.pr.new/larksuite/cli/@larksuite/cli@85cc5557a93e584ec9a1652112e81d019ae5645f🧩 Skill updatenpx skills add Lekkoo/cli#fix/update-check-timeout -y -g |
|
王伟达 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
Problem
lark-cli update --checkfails withcontext deadline exceededwhen the network path toregistry.npmjs.orghas high TLS handshake latency. This is common behind TUN-mode proxies (e.g. Clash Verge TUN), VPNs, or transcontinental routes.Root Cause
internal/update/update.gouses a hardcoded 5-second HTTP client timeout for the npm registry fetch:This timeout covers the entire request lifecycle (DNS + TCP + TLS + headers + body). Under TUN-mode proxies, the TLS handshake alone takes 4-6 seconds because traffic is intercepted at the virtual interface and re-routed through a proxy tunnel:
curlsucceeds because it has no default connect timeout. Go'shttp.Client.Timeout = 5sis too tight — the TLS handshake hasn't finished before the deadline fires.The 5s timeout also makes the failure non-deterministic: sometimes the TLS handshake completes in 4.3s and the check succeeds, sometimes it takes 5.9s and fails. This makes the bug hard to reproduce and diagnose.
Fix
Increase
fetchTimeoutfrom 5s to 15s:15s provides comfortable headroom for high-latency network paths while still failing fast on genuinely unreachable networks. The npm registry endpoint returns a tiny JSON payload (<1KB), so the extra timeout does not delay real failures meaningfully.
Verification
go build ./internal/update/— passesgo test ./internal/update/ -count=1— passesNotes
Switching Clash Verge between TUN / System Proxy / rule modes does not help — TUN is always intercepting traffic when enabled, and the TLS latency is inherent to the proxy round-trip. Setting
HTTP_PROXY/HTTPS_PROXYenv vars also does not help because the Go binary already useshttp.DefaultTransportwhich honors proxy env vars; the issue is the timeout, not proxy detection.Summary by CodeRabbit