当前版本：2603
web界面固件升级的时候，会弹窗升级失败，但是实际升级成功
上图的结果详情是：升级成功，但是等待一会，界面会弹窗升级失败
实际固件是升级成功的，这个问题如何定位？弹窗在哪个组件屏蔽
答案内容由AI生成，仅供参考：
根据您提供的信息，结合知识库中的相关内容，针对“实际升级成功，但 Web 界面弹窗‘升级失败’”的问题，定位思路和屏蔽建议如下。
一、问题定位
升级失败弹窗的本质是升级任务被某个环节上报为“失败”，尽管固件实际已经写入并生效。从知识库看，通常与 firmware_mgmt 收到的非零返回值 或 任务状态上报异常 有关。
1. 查看升级日志
- 日志路径：
/var/log/app.log（新版）或/var/log/app_debug_log_all（旧版） - 优先搜索以下关键字：
| 关键字 | 含义 |
|---|---|
Upgrade <某固件> process failed, ret=<非0返回值> |
firmware_mgmt 明确收到了来自多样硬件组件的升级失败信号，说明是“固件组件返回失败” |
Update task failed, task_id: xxx, res: -9 |
任务服务返回错误，但任务状态可能已到达 COMPLETED，容易导致“实际成功、界面报失败”的假象 |
upgrade failed, set_stage: DIFF_FINISH -> COMPLETED |
任务状态被置为 COMPLETED，但日志中同时出现 failed 记录 |
Upgrade ... failed |
操作日志中记录的失败事件，可用于定位失败发生时间点 |
2. 确认升级流程阶段
升级流程由 firmware_mgmt 管理，典型阶段包括：
INITIALIZE → DIFF_PREPARE → COMMON_PREPARE → PROCESS → COMMON_FINISH → COMPLETED
可在日志中搜索 set_stage 记录，确认任务实际走到了哪个阶段。如果固件实际已生效，但界面报失败，问题很可能发生在 finish 阶段或任务状态上报阶段。
3. 重点检查 finish 阶段返回值
知识库中有一个非常接近您场景的案例：
- 升级的 finish 阶段，
general_hardware组件的signal.lua会调用UpdateServiceUpdateServiceFinishReply函数，向firmware_mgmt返回该阶段的返回值。 - 如果该返回值为
-1，firmware_mgmt就会判定升级失败。 - 但该返回值理论上应由 process 阶段的
g_upgrade_ret赋值；如果 process 阶段成功，该值应为0，finish 阶段不应失败。 - 如果出现不一致，建议：
- 检查本地代码与社区主干逻辑是否有差异；
- 在
UpdateServiceUpdateServiceFinishReply附近增加打印g_upgrade_ret的值，确认是哪一环返回了非零值。
二、弹窗在哪个组件屏蔽
知识库没有明确给出“屏蔽弹窗”的具体代码文件或配置项，但可以确认以下事实：
- firmware_mgmt 是负责升级任务全生命周期管理的核心组件，包括任务状态跟踪、进度上报、错误通知。
- Web 界面获取升级结果通常依赖：
UpdateProgress：包含任务名、目标/当前版本、进度百分比、状态、错误码等信息；firmwareUpgradeDetailedResults：提供升级的详细结果文本。
因此，Web 界面弹窗中的“升级失败”提示，大概率来源于 firmware_mgmt 上报的任务失败状态或错误码。若要在界面屏蔽该弹窗，可从两条链路入手：
- 后端（firmware_mgmt）：调整在“实际升级成功但某一阶段返回非零值”场景下的失败判定逻辑，避免把成功任务标记为失败；
- 前端 / Web 后端：调整对
UpdateProgress或firmwareUpgradeDetailedResults返回状态的处理逻辑，不将已确认成功的任务渲染为“升级失败”。
由于知识库未给出屏蔽弹窗的具体修改位置，建议结合日志定位到具体返回非零值的组件（例如 general_hardware 的 finish 阶段），并与对应组件负责人确认如何修正返回值，或直接咨询 firmware_mgmt 开发人员确认弹窗判断逻辑。
firmware_mgmt组件没开源
还是得看一下日志，提示升级失败的原因，关注firmware_mgmt和general_hardware这两个组件的日志