Repository navigation
Conversation
总体结论：修改后合并AUTO-MAS-Project/AUTO-MAS #1912 宝宝，资源恢复和官方本体失败这次分得很清楚喵：半更新资源不能跳过，官方安装失败也不会被 MAS 偷偷清掉。静态审查没有确认的功能阻断，但当前格式 CI 已失败，后面的前端检查整段没执行，先补好这项再合。 MAA 管理器在首个实际运行账号前安排询问；恢复模块绑定本次标记，资源更新器继续负责完整暂存与校验合并。安装访问锁覆盖等待和写入，取消时等写线程停止，没有另开一套资源安装逻辑。 规范需要修复的 CI 门禁： 格式检查日志指出新增 test_maa_resource_recovery_choice.py:62不符合 Ruff 格式。任务在 Python 格式步骤结束，后续前端 lint、类型、格式、单元测试、词表检查全部跳过。请按仓库格式化规则调整这个测试，再确认整条检查通过；这不是生产恢复逻辑崩溃，也不能把被跳过的前端用例记成通过呀。 [规范 · P3，非阻断] 当前资源时间未知时，resource_install_recovery.py:59发送非空中文“未知”，英文、日文界面就不会使用自身的 Unknown/不明翻译。让前端处理空值即可。 规格未确认必须修改的功能问题。已核对无前端、拒绝、超时与取消不会清除标记，确认后的原始字节会在进入资源准备和最终合并前复查；完整资源清单校验、逐文件原子替换和最后写入版本文件仍由原入口负责。新询问仅进入 AutoProxy 首个实际运行账号，不属于原生配置会话弹窗。 有一个非阻断文案建议：按钮写“重新下载并修复”，但已有完整暂存通过全量摘要检查、且达到目标时间时会直接复用。保留这个复用是合理的，文案改成“校验并修复资源”更准确，不需要为了按钮文字额外下载喵。 验证情况已有 CI 的 Windows pytest 为 1810 passed、2 skipped，Ubuntu 为 1771 passed、40 skipped，Windows 验证包构建通过。新后端测试的“完整资源修复”用例替换了实际合并函数，只证明参数与调用衔接，不能视为真实安装验证。前端主动重连用例已静态检查，但本次 CI 因上述早退尚未执行它。 dot酱没有运行项目代码、测试或真实 Windows MAA/Electron 流程。规范侧保留 1 个非阻断 P3；规格侧没有确认功能缺陷，合并前仍需修复格式门禁并补齐被跳过的验证。 —— dot酱守着检查绿灯敬上 🐾 |
总体结论：可以合并AUTO-MAS-Project/AUTO-MAS #1912 · 格式修复复审 宝宝，Python 测试的空行和前端 computed 换行都补好了，前次被格式失败挡住的检查这次真正跑完啦。dot酱核对这两处都是格式调整，没有改变恢复行为，代码审查范围内已无必须修改项喵。当前 Windows/Ubuntu pytest 仍在运行，合并前还需确认本次完整 CI。 已读取当前格式任务日志：后续前端类型检查及测试均已执行，58 个测试文件共 308 项通过，Windows 验证包构建也成功。这里用的是新提交的结果，没有把前一版跳过的检查算成通过。 规格侧未确认新增缺陷；规范侧原有“未知”未本地化的 P3 仍非阻断。“重新下载并修复”的文案建议也不改变结论，已有完整暂存继续复用即可，不要为了按钮文字额外下载呀。 本轮仅静态核对与读取已有 CI，没有运行项目、测试或真实 MAA/Electron 流程。前次对资源修复调用链及测试替身范围的说明仍适用。 —— dot酱核过检查日志敬上 🐾 |
…ity and protected full-stage merge into AUTO-MAS-Project#1916 adapter
youngslin
changed the title
## 仅保留 #1916 公共自动恢复入口 本 PR 不再提供人工确认弹窗或自定义恢复 WebSocket。MAA 安装失败状态经统一公共入口接收、健康检查、恢复执行以及任务末尾异常汇总。 **MAA 本体官方安装失败：** 经官方已发布版本代码核对，`pending-update-failure.txt` 存在时，启动 MAA 会先清空 `UpdatePackage`。MAS 单独写入包路径再拉起 MAA.exe 并不能完成官方内部的重新登记流程。因此本 PR 不再虚假执行自动本体重试。只要官方失败标记尚未安全消除且无法证明已完成新版本，就阻止脚本任务继续，保留失败标记和原始包，明确提示用户先在 MAA 官方界面完成原生修复。也不擅自清理上游失败标记。 **MAS 资源半更新：** `.automas-resource-update.json` 继续经 #1916 自动重新获取完整资源、核验下载与身份，然后重新合并；不能通过旧资源时钟直接跳过。资源中断及官方本体失败同时存在时优先阻断本体，避免错误地完成部分资源更新。 保留 PE 检查、原生事务/进程锁和标记变化保护。新增使用真实 manager、adapter、公共恢复入口的测试，证明官方本体失败与完整包待处理时不会空转或误删原文件；资源单独失败仍自动重试。真实 MAA 官方 UI 修复的端到端验证尚未执行。 已废弃的 #1912 资源恢复弹窗逻辑没有保留。
背景
MAA 的更新分两套：本体完整包委托
MAA.Updater.exe，MAS 自己负责合并资源包。MAS 在覆盖资源后若意外中断会留下.automas-resource-update.json，因此本地资源可能半更新。关闭更新托管时目前直接拒绝运行，没有独立的恢复入口。变更
pending-update-failure.txt是上游安装器失败，不是 MAS 资源标记。发现该记录时立即停止并引导用户在 MAA 官方界面修复，绝不擅自删除上游标记/直接覆盖 MAA 本体。回归与风险
新增错误标记替换、取消保留原标记、无主界面关闭、成功重新走整包合并、关闭托管时官方失败标志不可绕过等测试；前端测试覆盖主动换连接时的孤儿弹窗。尚未进行真实 Windows MAA 官方更新器与资源合并端到端测试，CI 会执行项目既有全量 pytest、格式及构建。