feat: 适配focus.trace字段 - #313
Merged
Merged
Conversation
Contributor
There was a problem hiding this comment.
Hey - 我发现了 1 个问题
给 AI Agents 的提示
请根据以下代码审查评论进行修改:
## 单独评论
### 评论 1
<location path="src/utils/useMaaCallbackLogger.ts" line_range="323-324" />
<code_context>
- // 首先检查是否有 focus 字段,有则优先处理 focus 消息
+ // 首先检查是否有 focus 字段,有展示内容则优先处理 focus 消息
+ // (v2.9.1 起对象可以只配 trace 不配 content,这种没有展示内容,落回常规消息处理)
const focus = details.focus as Record<string, FocusTemplate> | undefined;
- if (focus && focus[message]) {
- const focusEntry = focus[message];
-
- // v2.3.0: 解析 focus 模板(支持字符串简写和对象完整写法)
- let focusTemplate: string;
- let displayChannels: FocusDisplayChannel[];
- if (typeof focusEntry === 'string') {
- focusTemplate = focusEntry;
- displayChannels = ['log'];
- } else {
- focusTemplate = focusEntry.content;
- const d = focusEntry.display;
- displayChannels = d ? (Array.isArray(d) ? d : [d]) : ['log'];
- }
+ const focusTemplateEntry = focus?.[message];
+ const focusEntry = focusTemplateEntry ? parseFocusEntry(focusTemplateEntry) : undefined;
+ if (focusEntry) {
</code_context>
<issue_to_address>
**issue (bug_risk):** 通过判断 `focusTemplateEntry` 的真值来做保护,会导致具有空字符串内容的合法 focus 条目被忽略。
由于对 `focusTemplateEntry` 使用了真值判断,像 `''` 这样(或其他“假值但合法”的模板)不会被传递给 `parseFocusEntry`,代码会悄悄地回退到默认路径。由于 `parseFocusEntry` 已经处理了空内容并决定何时返回 `undefined`,你可以通过改为检查键是否存在来简化逻辑并提升健壮性:
```ts
const focus = details.focus as Record<string, FocusTemplate> | undefined;
if (focus && message in focus) {
const focusEntry = parseFocusEntry(focus[message]);
if (focusEntry) {
const { content: focusTemplate, displayChannels } = focusEntry;
// ...
}
}
```
这样可以避免丢弃那些有意使用空或其他假值模板的配置,并将“是否展示”的决策保留在 `parseFocusEntry` 内部。
</issue_to_address>帮我变得更有用!请在每条评论上点击 👍 或 👎,我会根据你的反馈改进审查质量。
Original comment in English
Hey - I've found 1 issue
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="src/utils/useMaaCallbackLogger.ts" line_range="323-324" />
<code_context>
- // 首先检查是否有 focus 字段,有则优先处理 focus 消息
+ // 首先检查是否有 focus 字段,有展示内容则优先处理 focus 消息
+ // (v2.9.1 起对象可以只配 trace 不配 content,这种没有展示内容,落回常规消息处理)
const focus = details.focus as Record<string, FocusTemplate> | undefined;
- if (focus && focus[message]) {
- const focusEntry = focus[message];
-
- // v2.3.0: 解析 focus 模板(支持字符串简写和对象完整写法)
- let focusTemplate: string;
- let displayChannels: FocusDisplayChannel[];
- if (typeof focusEntry === 'string') {
- focusTemplate = focusEntry;
- displayChannels = ['log'];
- } else {
- focusTemplate = focusEntry.content;
- const d = focusEntry.display;
- displayChannels = d ? (Array.isArray(d) ? d : [d]) : ['log'];
- }
+ const focusTemplateEntry = focus?.[message];
+ const focusEntry = focusTemplateEntry ? parseFocusEntry(focusTemplateEntry) : undefined;
+ if (focusEntry) {
</code_context>
<issue_to_address>
**issue (bug_risk):** Guarding on `focusTemplateEntry` truthiness can drop valid focus entries with empty-string content.
Because `focusTemplateEntry` is checked by truthiness, values like `''` (or other falsy-but-valid templates) are never passed to `parseFocusEntry`, and the code silently falls back to the default path. Since `parseFocusEntry` already handles empty content and decides when to return `undefined`, you can simplify and make this more robust by checking key presence instead:
```ts
const focus = details.focus as Record<string, FocusTemplate> | undefined;
if (focus && message in focus) {
const focusEntry = parseFocusEntry(focus[message]);
if (focusEntry) {
const { content: focusTemplate, displayChannels } = focusEntry;
// ...
}
}
```
This avoids dropping configurations that intentionally use empty or other falsy templates and keeps the “no display” decision inside `parseFocusEntry`.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
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.
opus5.0


MaaXYZ/MaaFramework#1428