fix(PipelineTask): Batch OCR 对 AND/OR 组合识别节点触发失效

[ocsin1]

Summary by Sourcery

修复批量 OCR 流水线在处理组合 AND/OR 识别节点时的触发逻辑。

Bug 修复：

• 确保批量 OCR 的触发是基于实际贡献条目的节点，从而恢复 AND/OR 组合识别节点的正确行为。

增强功能：

• 在批量 OCR 计划中跟踪所属节点名称，以便将条目正确关联到其来源的流水线节点。

Original summary in English

Summary by Sourcery

Fix batch OCR pipeline trigger handling for combined AND/OR recognition nodes.

Bug Fixes:

• Ensure batch OCR is triggered based on the nodes that actually contribute entries, restoring correct behavior for AND/OR combined recognition nodes.

Enhancements:

• Track owner node names in batch OCR plans to correctly associate entries with their originating pipeline nodes.

[sourcery-ai]

Hey - 我在这里提供了一些高层次的反馈：

• 现在 owner_node_names 用于触发，而 node_names 仍然与其并存，建议考虑要么重命名或在文档中说明这两组之间的区别，要么如果 node_names 已不再需要就将其移除，以避免给未来的维护者带来困惑。
• 在 prepare_batch_ocr 中，你依赖 ctx.plan.entries.size() 的变化来推断 owner 节点；如果未来有改动对 collect_ocr_from_reco 进行修改，以删除条目或分多步添加条目，这种隐式耦合可能会失效——建议将这部分 ownership 跟踪逻辑封装到 collect_ocr_from_reco 内部，或通过返回值显式表明是否有条目被添加。

面向 AI Agent 的提示

Please address the comments from this code review:

## Overall Comments
- Now that `owner_node_names` is used for triggering and `node_names` remains alongside it, consider either renaming or documenting the distinction between the two sets, or removing `node_names` if it is no longer needed, to avoid confusion for future maintainers.
- In `prepare_batch_ocr`, you rely on `ctx.plan.entries.size()` deltas to infer owner nodes; if a future change modifies `collect_ocr_from_reco` to remove entries or add them in multiple steps, this implicit coupling could break—consider encapsulating this ownership tracking inside `collect_ocr_from_reco` or returning explicit information about whether entries were added.

---

Sourcery 对开源项目是免费的——如果你觉得我们的评审有帮助，欢迎分享 ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{帮我变得更有用！请在每条评论上点击 👍 或 👎，我会根据你的反馈改进评审质量。}

Original comment in English

Hey - I've left some high level feedback:

• Now that owner_node_names is used for triggering and node_names remains alongside it, consider either renaming or documenting the distinction between the two sets, or removing node_names if it is no longer needed, to avoid confusion for future maintainers.
• In prepare_batch_ocr, you rely on ctx.plan.entries.size() deltas to infer owner nodes; if a future change modifies collect_ocr_from_reco to remove entries or add them in multiple steps, this implicit coupling could break—consider encapsulating this ownership tracking inside collect_ocr_from_reco or returning explicit information about whether entries were added.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Now that `owner_node_names` is used for triggering and `node_names` remains alongside it, consider either renaming or documenting the distinction between the two sets, or removing `node_names` if it is no longer needed, to avoid confusion for future maintainers.
- In `prepare_batch_ocr`, you rely on `ctx.plan.entries.size()` deltas to infer owner nodes; if a future change modifies `collect_ocr_from_reco` to remove entries or add them in multiple steps, this implicit coupling could break—consider encapsulating this ownership tracking inside `collect_ocr_from_reco` or returning explicit information about whether entries were added.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[ocsin1]

• 在 prepare_batch_ocr 中，你依赖 ctx.plan.entries.size() 的变化来推断 owner 节点；如果未来有改动对 collect_ocr_from_reco 进行修改，以删除条目或分多步添加条目，这种隐式耦合可能会失效——建议将这部分 ownership 跟踪逻辑封装到 collect_ocr_from_reco 内部，或通过返回值显式表明是否有条目被添加

node_names去重+依赖检查,和owner_node_names职责不相同

• 现在 owner_node_names 用于触发，而 node_names 仍然与其并存，建议考虑要么重命名或在文档中说明这两组之间的区别，要么如果 node_names 已不再需要就将其移除，以避免给未来的维护者带来困惑。

上下文一共就5行,一眼能看到吧,这样反而增加复杂度