Conversation
|
@qqqqqf-q Please complete the following information using the template:
Editing the description triggers another check; format feedback does not block or cancel code CI. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 63df4b646a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } | ||
| a.inputHints[token] = stop | ||
| a.mu.Unlock() | ||
| go a.renewInputHint(ctx, client, target.ID, token, stop) |
There was a problem hiding this comment.
Detach hint renewal from the short-lived status context
For real inbound turns, notifyProcessingStarted passes a timeout context and executes defer cancel() immediately after ProcessingStarted returns (internal/channel/inbound/channel.go:2674-2676). Consequently, this goroutine sees ctx.Done() before its first 50-second tick and exits, so replies lasting over 60 seconds never renew the QQ typing hint. Use a turn-lifetime context or make the renewal loop depend only on its explicit stop channel.
Useful? React with 👍 / 👎.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Codex review (PR felinics#1275): 真实调用方 notifyProcessingStarted 用短超时 上下文包裹并在 ProcessingStarted 返回后立即 cancel,续期协程在首个 50s tick 前就随 ctx.Done 退出,>60s 的 turn 永远等不到续发。续期循环 改跑 context.WithoutCancel(ctx),只由 stop 通道终止;补取消后存活的 回归测试。
X 用户反馈 QQ 渠道回复不实时(等大模型全量生成完才推送)。QQ 官方
2026-07 上线单聊流式端点 /v2/users/{openid}/stream_messages,支持
markdown 分片;群聊/频道无流式或消息编辑能力,维持原行为。
- C2C 回复经 stream_messages 分片下发:replace 模式累计全文(前缀
恒一致,QQ 客户端静默丢中间片也不损内容),约 1s 节流、首片即时,
末片 input_state=10 完结;任一分片失败回退原有攒发
- 新增 enableStreaming 配置(默认开,仅 markdownSupport 开启时生效)
- input_hint 60s 过期自动续发(最多 3 次,避开 C2C 被动回复 4 次
配额),Completed/Failed 停止续期;续期协程跑 WithoutCancel 上下
文——真实调用方在 ProcessingStarted 返回后即 cancel 回调上下文
- receiver 重连阶梯 5 分钟封顶,修复白名单/频控类持续失败高频打爆
网关配额
86544dc to
6986206
Compare
背景
用户反馈 QQ 渠道两个问题:回复不实时(要等模型全量生成完才推送,长回复像服务器挂了)、markdown 渲染异常。
调研 QQ 官方 Bot API 现状:
POST /v2/users/{openid}/stream_messages(分片携带同一stream_msg_id、index递增、input_state1=生成中/10=结束,支持content_type: markdown,限频 50 QPS)改动
1. C2C 单聊流式(
stream.go/client.go)OpenStream在目标为 c2c、存在被动回复锚点 msg_id、markdownSupport与enableStreaming均开启时接入stream_messagesinput_state=10完结enableStreaming(默认开启);群聊/频道不经过此路径,行为不变2. input_hint 续期(
qq.go)3. receiver 重连 backoff 5 分钟封顶(
receive.go)接口调用超过频率限制)4. markdown 不做降级
测试
自动化
go test ./internal/channel/adapters/qq/全绿,新增 7 例:累计分片内容与 index/stream_msg_id 递进、分片失败回退攒发、短回复单片、节流行为、stream shard 请求体结构、input hint 续期注册/停止/幂等golangci-lint run ./internal/channel/adapters/qq/...干净;go test ./internal/arch/通过;pre-commit 钩子全仓测试绿真机(QQ 桌面端 QQNT,个人开发者测试 bot,C2C 私聊)
40034128(被动回复超限)、零40007(前缀冲突)——实证流式分片不消耗被动回复次数(官方文档未写明这一点)/help、/model等斜杠命令正常未验证