Step4Report.vue 前端在API调用报错后重复提取日志循环

[limingcong2001]

可以看到日志不断循环提取，尝试debug了半天但是只能找到问题源应该在Step4Report.vue 里面，可惜没接触过前端给不出修改意见，就报个错吧。

[dosubot[bot]]

Hi @limingcong2001! I'm Dosu and I’m helping the MiroFish team.

感谢你详细的 bug 报告！我找到了问题的根本原因。

问题根源：Step4Report.vue 的 fetchAgentLog 函数 只监听了 report_complete 事件来停止轮询，但缺少对 error 事件的处理。后端在报告生成失败时会发送 action: "error" 的日志，但前端忽略了这个事件，导致永远等不到 report_complete，定时器每 2 秒继续请求 API。

同时，catch 块 只输出警告而不停止轮询，所以 500 错误也不会终止循环。

推荐修复：在 第 2052 行 的 if (log.action === 'report_complete') 之前添加：

if (log.action === 'error') {
  addLog(`❌ 报告生成失败: ${log.details?.error || '未知错误'}`, 'error')
  reportStatus.value = 'failed'
  stopPolling()  // 关键：停止轮询
  return
}

另外建议在 catch 块中添加错误计数器，连续失败 3 次后自动停止轮询，防止网络故障时的无限重试。

值得注意的是，Issue #14 报告过 Step3Simulation.vue 存在类似问题，建议一并检查。

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[666ghj]

Note

🤖 Automated maintainer response — Generated by the MiroFish triage agent and checked against main@4ebb2ed6 on 2026-07-21. Posted with maintainer authorization; a maintainer may revise it.

We rechecked the current default branch. The backend can still emit an action: "error" report log, while Step4Report.vue stops polling only after report_complete; the request-error handler also logs a warning without applying a bounded failure shutdown. The existing diagnosis is therefore broadly consistent with the current source, but its proposed change has not been merged and this should not be treated as resolved.

We are keeping this open until a focused Issue or pull request tracks terminal-error handling and bounded retry behavior. Please redact API keys and private input data from any additional logs.

[666ghj]

🤖 Sent by the MiroFish repository maintenance agent.

The error-polling gap remains in main@7657031a: fetchAgentLog stops polling for report_complete, but does not handle the terminal error log, and its request-error catch only warns. This has not been resolved by the earlier report-content fixes.

We are keeping the discussion open. A focused correction should stop polling on confirmed terminal failure while distinguishing it from a transient network failure, preserve available report sections and allow an explicit retry. Report-resume proposal #547 also needs this frontend lifecycle covered; its presence does not establish a completed fix.