Conversation
Contributor
审查者指南（Reviewer's Guide）扩展多消息解码能力，通过 无过滤条件时 WebSocket 心跳事件发送的时序图sequenceDiagram
participant OB11WebSocket
participant Context
participant Client
OB11WebSocket->>Context: interval(callback, heartInterval)
Context-->>OB11WebSocket: schedule periodic callback
loop every heartInterval
OB11WebSocket->>OB11WebSocket: create OB11HeartbeatEvent(online, true, heartInterval)
OB11WebSocket->>Client: reply(socket, OB11HeartbeatEvent)
end
participant OB11WebSocketReverse
participant ReverseContext as Context_reverse
participant WsClient
OB11WebSocketReverse->>ReverseContext: interval(callback, heartInterval)
ReverseContext-->>OB11WebSocketReverse: schedule periodic callback
loop every heartInterval when WsClient exists
OB11WebSocketReverse->>OB11WebSocketReverse: create OB11HeartbeatEvent(online, true, heartInterval)
OB11WebSocketReverse->>WsClient: reply(wsClient, OB11HeartbeatEvent)
end
文件级变更
提示与命令与 Sourcery 交互
自定义你的体验访问你的 控制面板 以：
获取帮助Original review guide in EnglishReviewer's GuideExpands multi-message decoding to distinguish image and video rich media by businessType while simplifying WebSocket heartbeat behavior by always emitting heartbeat events, plus a minor doc path adjustment. Sequence diagram for WebSocket heartbeat emission without filteringsequenceDiagram
participant OB11WebSocket
participant Context
participant Client
OB11WebSocket->>Context: interval(callback, heartInterval)
Context-->>OB11WebSocket: schedule periodic callback
loop every heartInterval
OB11WebSocket->>OB11WebSocket: create OB11HeartbeatEvent(online, true, heartInterval)
OB11WebSocket->>Client: reply(socket, OB11HeartbeatEvent)
end
participant OB11WebSocketReverse
participant ReverseContext as Context_reverse
participant WsClient
OB11WebSocketReverse->>ReverseContext: interval(callback, heartInterval)
ReverseContext-->>OB11WebSocketReverse: schedule periodic callback
loop every heartInterval when WsClient exists
OB11WebSocketReverse->>OB11WebSocketReverse: create OB11HeartbeatEvent(online, true, heartInterval)
OB11WebSocketReverse->>WsClient: reply(wsClient, OB11HeartbeatEvent)
end
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Hey - 我发现了 1 个问题，并给出了一些整体性的反馈：
businessType检查(businessType === 10 || businessType === 20)和(businessType === 11 || businessType === 21)引入了若干“魔法数字”；建议将这些值提取为有含义的常量或枚举，以便让意图更清晰，并降低未来出错的风险。- 在
serviceType === 48分支中，你现在会解码Media.MsgInfo并在图片和视频路径中都访问msgInfoBody[0]及其index；建议将这部分逻辑抽取成一个小的辅助函数，以避免重复并让富媒体解码流程更易于维护。
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The `businessType` checks `(businessType === 10 || businessType === 20)` and `(businessType === 11 || businessType === 21)` introduce several magic numbers; consider extracting these into named constants or an enum to make the intent clearer and reduce the chance of future mistakes.
- In the `serviceType === 48` branch you now decode `Media.MsgInfo` and access `msgInfoBody[0]` and its `index` in both image and video paths; consider factoring this into a small helper to avoid duplication and make the rich media decoding flow easier to maintain.
## Individual Comments
### Comment 1
<location path="src/onebot11/helper/decodeMultiMessage.ts" line_range="40-31" />
<code_context>
+ file_size: info!.fileSize!.toString(),
+ }
+ }
+ } else if (serviceType === 48 && (businessType === 11 || businessType === 21)) {
+ const { msgInfoBody } = Media.MsgInfo.decode(pbElem)
+ const { index } = msgInfoBody[0]
+ const url = await ctx.ntFileApi.getVideoUrlByPacket(index.fileUuid, businessType === 21)
+ segment = {
+ type: OB11MessageDataType.Video,
+ data: {
+ file: index.info.fileName,
+ url,
</code_context>
<issue_to_address>
**issue (bug_risk):** Guard against missing or malformed `msgInfoBody[0].index` when decoding video messages.
This branch dereferences `msgInfoBody[0].index` (including `fileUuid` and `info` fields) without checks. If `msgInfoBody` is empty or `index`/`info` is absent (e.g., upstream proto/server issues), this will throw and can crash the decode pipeline. Please add a minimal guard (e.g., early-return when `msgInfoBody[0]?.index?.info` or `fileUuid` is missing) so malformed packets fail gracefully instead of causing runtime errors.
</issue_to_address>Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Original comment in English
Hey - I've found 1 issue, and left some high level feedback:
- The
businessTypechecks(businessType === 10 || businessType === 20)and(businessType === 11 || businessType === 21)introduce several magic numbers; consider extracting these into named constants or an enum to make the intent clearer and reduce the chance of future mistakes. - In the
serviceType === 48branch you now decodeMedia.MsgInfoand accessmsgInfoBody[0]and itsindexin both image and video paths; consider factoring this into a small helper to avoid duplication and make the rich media decoding flow easier to maintain.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The `businessType` checks `(businessType === 10 || businessType === 20)` and `(businessType === 11 || businessType === 21)` introduce several magic numbers; consider extracting these into named constants or an enum to make the intent clearer and reduce the chance of future mistakes.
- In the `serviceType === 48` branch you now decode `Media.MsgInfo` and access `msgInfoBody[0]` and its `index` in both image and video paths; consider factoring this into a small helper to avoid duplication and make the rich media decoding flow easier to maintain.
## Individual Comments
### Comment 1
<location path="src/onebot11/helper/decodeMultiMessage.ts" line_range="40-31" />
<code_context>
+ file_size: info!.fileSize!.toString(),
+ }
+ }
+ } else if (serviceType === 48 && (businessType === 11 || businessType === 21)) {
+ const { msgInfoBody } = Media.MsgInfo.decode(pbElem)
+ const { index } = msgInfoBody[0]
+ const url = await ctx.ntFileApi.getVideoUrlByPacket(index.fileUuid, businessType === 21)
+ segment = {
+ type: OB11MessageDataType.Video,
+ data: {
+ file: index.info.fileName,
+ url,
</code_context>
<issue_to_address>
**issue (bug_risk):** Guard against missing or malformed `msgInfoBody[0].index` when decoding video messages.
This branch dereferences `msgInfoBody[0].index` (including `fileUuid` and `info` fields) without checks. If `msgInfoBody` is empty or `index`/`info` is absent (e.g., upstream proto/server issues), this will throw and can crash the decode pipeline. Please add a minimal guard (e.g., early-return when `msgInfoBody[0]?.index?.info` or `fileUuid` is missing) so malformed packets fail gracefully instead of causing runtime errors.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| const url = parsedUrl.href + (imageAppid === '1406' ? rkeyData.private_rkey : rkeyData.group_rkey) | ||
| const { info } = richMediaInfo.msgInfoBody[0].index! | ||
| const { pic } = richMediaInfo.extBizInfo! | ||
| segment = { |
Contributor
There was a problem hiding this comment.
issue (bug_risk): 在解码视频消息时，需要防范 msgInfoBody[0].index 缺失或格式异常。
当前分支在没有任何检查的情况下直接解引用 msgInfoBody[0].index（包括其中的 fileUuid 和 info 字段）。如果 msgInfoBody 为空，或者 index/info 缺失（例如上游 proto/服务端的问题），这里会抛异常并导致解码流水线崩溃。请添加一个最小化的防护（例如，当 msgInfoBody[0]?.index?.info 或 fileUuid 缺失时直接提前返回），这样可以让格式异常的包以优雅失败的方式处理，而不是引发运行时错误。
Original comment in English
issue (bug_risk): Guard against missing or malformed msgInfoBody[0].index when decoding video messages.
This branch dereferences msgInfoBody[0].index (including fileUuid and info fields) without checks. If msgInfoBody is empty or index/info is absent (e.g., upstream proto/server issues), this will throw and can crash the decode pipeline. Please add a minimal guard (e.g., early-return when msgInfoBody[0]?.index?.info or fileUuid is missing) so malformed packets fail gracefully instead of causing runtime errors.
Test Report
✅ All tests passed |
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.
Summary by Sourcery
处理更多富媒体消息类型，并调整 WebSocket 心跳行为。
增强内容：
Original summary in English
Summary by Sourcery
Handle additional rich media message types and adjust WebSocket heartbeat behavior.
Enhancements: