Repository navigation
Conversation
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| raise _DownloadError("资源增量基线已失效，必须重新下载全量包") | ||
| complete = stage_tmp / "complete" | ||
| shutil.copytree(_STAGE_DIR / "resource", complete) | ||
| merge_package_tree(root, complete) | ||
| root = complete | ||
| expected = len(resource_tree_hashes(root)) | ||
| else: | ||
| expected = count_zip_entries(zip_path, prefix=prefix) | ||
| file_hashes = resource_tree_hashes(root) | ||
| _MANIFEST_FILE.unlink(missing_ok=True) | ||
| if _STAGE_DIR.exists(): |
There was a problem hiding this comment.
Bug: Discrepancy in counting .gitignore files during incremental stage validation causes _DownloadError and forces unexpected fallbacks to full downloads.
Severity: MEDIUM
Suggested Fix
Align file counting between expected and actual. Either ignore .gitignore files when calculating actual via rglob, or exclude .gitignore during copytree when building the incremental stage tree.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: app/task/MAA/tools/resource_update.py#L484-L500
Potential issue: In `_build_stage`, the expected file count for incremental packages is
calculated via `len(resource_tree_hashes(root))`, which ignores `.gitignore` files.
However, `actual` is calculated by counting all files in `_STAGE_DIR / 'resource'`,
including `.gitignore` files copied from the baseline tree during `copytree`. If
`.gitignore` files exist in the baseline directory, `actual` exceeds `expected`, raising
`_DownloadError` and causing incremental updates to fail and fall back to full package
downloads every time.
Did we get this right? 👍 / 👎 to inform future reviews.
| ) -> Path: | ||
| """本体更新共享缓存目录：按系统、架构、通道隔离，互不覆盖。""" | ||
| return Path.cwd() / "data" / "maa_update" / "software" / os_name / arch / channel | ||
| root = Path.cwd() / "data" / "maa_update" / "software" / os_name / arch / channel | ||
| return ( | ||
| root / ("base-" + hashlib.sha256(base_version.encode()).hexdigest()[:16]) | ||
| if base_version | ||
| else root | ||
| ) | ||
|
|
||
|
|
||
| def load_cache_manifest(cache_dir: Path) -> dict[str, str] | None: |
There was a problem hiding this comment.
Bug: Versioned base-* cache directories for incremental software updates are never cleaned up, resulting in unbounded disk usage.
Severity: LOW
Suggested Fix
Implement a cleanup routine to remove obsolete base-* directories within {channel} when a new software package is cached or after an update completes successfully.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: app/task/MAA/tools/software_package.py#L76-L91
Potential issue: `software_cache_dir` creates versioned cache directories prefixed with
`base-<hash>` when a base version is specified. Because there is no pruning mechanism or
cleanup routine for old `base-*` directories, each incremental update leaves past
package caches behind, causing cumulative unbounded disk space consumption over multiple
updates.
Also affects:
app/task/MAA/tools/software_update.py:466~491app/task/MAA/tools/software_package.py:287~298
Did we get this right? 👍 / 👎 to inform future reviews.
总体结论：修改后合并AUTO-MAS-Project/AUTO-MAS #1949 宝宝，这次没有另起一套安装器，MAA 继续交给官方更新入口，MFW 家族也沿用了现有的新版本构建与登记流程，这个边界保留得好喵。不过增量路径还漏了两处：一处把合法资源缓存误判成损坏，另一处没接到真正需要回退全量的异常，先补好再合啦。 配置和前端负责保存全量/增量偏好；MAA 软件模块准备更新包，资源模块先拼出完整缓存再分发；MaaFW 更新模块则在临时目录构建、校验新版本，通过后才登记并切换。下面两项都是静态源码推演，未执行更新或复现。 MAA 资源更新[逻辑 · P2] 基线含
|
youngslin
changed the title
总体结论：可以合并宝宝，上一轮两处问题都补好了喵：资源增量复制已统一排除 新增缓存清理也核对过了：与取包、复制共用通道锁，保留近期和当前缓存，不会顺手删掉安装目录里的待更新包。合入 dev 后的配置衔接未发现新的必须修改项，这次可以放行啦。 dot酱只做了静态复核，未执行测试或真实安装更新。 —— 把增量回退这条线检查完的 dot酱敬上 🐾 |
摘要
审查修复
.gitignore时，重建增量缓存采用与分发相同的忽略规则；保留未改文件及摘要校验，不再误触发全量。UpdateApplyError → PayloadError → MaaFWProjectUpdateError链；登记前仅回退一次全量。真实坏指纹、取消、两种磁盘错误、登记后回调失败及全量请求仍返回坏增量均有回归；旧载荷内容全程保持不变。只隔离 HTTP 和磁盘故障，不替换构建、校验或登记逻辑。测试与验证
c62ecffd557f5c3597eb5e53d7e79fc93fafa39f，已合并上游dev的5dc79aebd并解决三种语言与统计覆盖文档冲突。uv run --no-sync python -m pytest tests/task/test_maa_fluxdown_update.py tests/task/test_maafw_update_fallback.py -k 'delta_fallback_uses_real or resource_delta_rebuilds or prunes_old_baselines' -q -p no:cacheprovider --tb=short：9 passed。corepack yarn test --run：358 passed；corepack yarn typecheck、lint、format:check通过，lint 仅有原有 QueueDeleteButton 属性默认值警告。ruff format --check .、相关文件 Ruff 检查、uv lock --check、更新日志碎片与 diff 检查通过。check_reverts仅提示增量接口签名与夹具的对应调整；同日新版突破旧额度限制的原回归仍保留并通过。corepack yarn e2e --grep 'package mode persists'：2 passed，隔离配置、不填写 CDK，覆盖 MAA/MaaEnd 禁用状态、选择增量、保存、风险提示、刷新保留。产出截图、HTML 报告和 trace；corepack yarn e2e:check通过。05b516305872c8b8a41fa0235d5ecfedef0157d1822dbe7147cc3112c00477a4。apply_update入口安装到独立临时目录，安装回执、目标版本/架构及用户配置保留均通过；没有启动 MaaEnd 或游戏，没有修改用户实际安装。已知验证边界
c62ecffd5，Windows）：uv run --no-sync python -m pytest tests -q -p no:cacheprovider --tb=short：2076 passed、1 skipped、1 failed，17 subtests passed。唯一失败仍为tests/utils/test_fluxdown_detect_managed_priority.py::test_incomplete_managed_fluxdown_falls_back：本机完整res/fluxdown-cli优先于夹具的外部目录。此前未修改上游5aa609284独立工作树在相同工作目录已复现同一失败；该检测实现及测试从5aa609284到本次合并的5dc79aebd均无变化，本 PR 也未修改。没有新增测试失败。选项名称已统一为“全量更新 / 增量更新”，默认仍为全量；文案调整后类型检查、格式检查与两个更新设置组件测试通过。