fix: 私聊引用消息 reply 段丢失,records 命中时直接用 msgId 构造并携带被引用文本 - #2016
Open
eolynya wants to merge 1 commit into
Open
Conversation
📦 构建产物
📋 构建信息
🚀 快速安装 (Linux)直连(需要能访问 GitHub) curl -sSL https://github.com/NapNeko/napcat-pr-release/releases/download/pr-2016-3313df7/install.sh | bash加速(国内推荐,ghfast.top) curl -sSL https://gh.llkk.cc/https://github.com/NapNeko/napcat-pr-release/releases/download/pr-2016-3313df7/install.sh | bash
|
私聊中引用消息的 replayMsgSeq 常被解析为 0,原有三种查询方法+协议兜底必然全部失败, reply 段被静默丢弃(NapNeko#1508 同场景)。而同一事件 records[]/sourceMsgIdInRecords 已携带 被引用消息完整记录(真实 msgId、文本),原实现仅对两个特定账号走此捷径。 现将捷径推广为 records 命中即直用 msgId,并携带 sourceMsgTextElems 文本作为可选 text 字段。
eolynya
force-pushed
the
fix/private-reply-quote
branch
from
August 16, 2026 05:46
61c6e84 to
3313df7
Compare
📋 构建信息
🚀 快速使用拉取镜像 docker pull mlikiowa/napcat-docker:pr-2016-3313df7启动容器 docker run -d \
--name napcat-pr-test \
-e NAPCAT_UID=$(id -u) \
-e NAPCAT_GID=$(id -g) \
-e WEBUI_TOKEN=napcat \
-p 6099:6099 \
-p 3000:3000 \
-p 3001:3001 \
-v ./napcat/config:/app/napcat/config \
-v ./napcat/QQ:/app/.config/QQ \
mlikiowa/napcat-docker:pr-2016-3313df7
|
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
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.
问题描述
私聊中引用(回复)消息时,OneBot 事件里丢失 reply 段——
message数组只剩 text 段,下游框架收不到引用信息(如reply_to_id=None)。群聊不受影响。复现步骤
message数组中没有{"type":"reply",...}段,raw_message也只剩纯文本根因分析
引用消息的原始
replyElement中,replayMsgSeq被解析为"0"(引用 bot 或自己发的消息时尤甚,peerUin同样为 0),而replyElement的转换逻辑依赖replayMsgSeq走三种查询方法 + 协议兜底:全部失败后
return null,reply 段被静默丢弃。但同一事件的
records[]与sourceMsgIdInRecords字段携带了被引用消息的完整记录(真实 msgId、发送者、时间、文本内容)。现有代码只在records.peerUin属于两个特定账号(284840486/1094950020)时才直接用records.msgId构造 reply 段——其他账号走必然失败的 seq 查询链。相关 issue:#1508(BOT发起的私聊消息被引用回复时获取不到引用消息)、#477(私聊引用丢 reply 段)。
修复方案
records 命中(
msgId === sourceMsgIdInRecords)且 msgId 有效时,直接用records.msgId构造 reply 段,不再依赖 seq 查询;同时从sourceMsgTextElems提取被引用文本,作为可选text字段携带(下游可直接使用,无需二次查询——NapCat 的get_msg对 bot 消息等场景同样会查不到)。replyElement:把「特定账号捷径」推广为「records 命中即直用」(records.msgId即被引用消息的真实 msgId,查询链本就多余)createReplyData:新增可选text参数OB11MessageReplySchema:data 新增可选text字段(向后兼容,不改变现有字段语义)测试结果
message数组正确输出{"type":"reply","data":{"id":"<shortId>","text":"<被引用文本>"}},下游reply_to_id/reply_to_text均正常兼容性
text为 Optional 新字段,不发送时行为与原来完全一致