fix(qq): route long Send() through HTTP to dodge 15s WS timeout (#1474)#1480
Open
chenhg5 wants to merge 1 commit into
Open
fix(qq): route long Send() through HTTP to dodge 15s WS timeout (#1474)#1480chenhg5 wants to merge 1 commit into
chenhg5 wants to merge 1 commit into
Conversation
Long replies (~2.5KB+) always tripped the hardcoded 15s timeout in
callAPI because the OneBot readLoop serves both inbound events and
outbound replies — long sends queue behind inbound traffic and stall.
New `send_via_http` config knob (default "auto"):
- "auto" → WS for <=512 byte messages, HTTP for longer ones.
Falls back to WS when http_url is unset.
- "always" → always HTTP (requires http_url); falls back to WS when
absent so unconfigured deployments still deliver.
- "never" → always WebSocket, even for long messages.
SendFile() and SendImage() are unaffected — separate code paths.
Tests cover: short-msg WS path, long-msg HTTP fallback (2500B),
private-vs-group, threshold boundary, mode=always/never, auto with
no http_url, invalid config value (falls back to auto), and a
table-driven shouldUseHTTP test.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1474
问题
Long replies (~2.5KB+) always timed out on QQ WebSocket send. Root cause:
callAPIshares the WS connection readLoop with inbound events, so a long outbound reply queues behind inbound traffic and trips the hardcoded 15s timeout — leaving the bot silent in group chats for long-form agent output.改动
New
send_via_httpconfig knob (default"auto") on the QQ OneBot platform:autohttp_urlis unset.alwayshttp_url); falls back to WS when absent.neverInvalid values fall back to
"auto"with aWARNlog.SendFile()andSendImage()are unaffected (separate code paths). HTTP path uses existingcallHTTPAPI(120s timeout, dedicated connection).触发条件 / trade-off
Reporter (#1474) proposed a 512-byte threshold — fixes the immediate symptom with zero config churn. Adding
send_via_httplets users override either direction:"always"— paranoid users who want every send off the shared WS path"never"— users who trust WS and don't want HTTP exposurehttp_urlis empty? Failing every send because the user didn't configure HTTP would be a regression. Better to deliver via the available path. Matches existingSendFile()behavior.测试
新增 9 个测试 + 1 个表驱动 helper 测试。Mock NapCat 复用了
TestStart_FetchesSelfIDWithoutTimeout的模式，单个httptest.Server同时承载 WS（receive + default send）和 HTTP（fallback 路径），每个 surface 用 atomic counter 记录调用次数以便断言。验证
gofmt -l platform/qq/— cleango vet ./platform/qq/...— cleango test ./platform/qq/...— all pass不做什么
SendImage()/SendFile()既有路径callAPI的 15s timeout（HTTP 旁路才是 fix）