Restored install that pauses before its first download-started signal cannot be restarted (restart_failed no-ops, marker loses resume metada

快速结论：这个报错通常出现在从磁盘 install marker 恢复的安装任务上：恢复后的任务在第一次 download-started 信号之前就被服务器用 416 拒绝而进入 PAUSED，此时点击 restart 会静默失效（no-op），任务卡在 PAUSED。优先排查恢复路径下 download_parts 是否为空，以及 restart 逻辑是否回退读取 multifile job 的 parts。

适用环境：Issue 已确认的工具为 InvokeAI，涉及多文件安装（multifile install，如 HF diffusers 模型）与 install marker 恢复流程；具体 Python、CUDA、显卡版本在 Issue 中未提供，无需补写。

最快修复方案：暂无确认的一步修复方案。该 Issue 已由维护者标记为 Fixed，需升级到包含修复的 InvokeAI 版本；在修复版本可用前，Issue 中提到的唯一规避方式是取消安装并从零重新导入（re-import from scratch）。

注意事项：重启无效并不会自动恢复，且 PAUSED 状态重写 install marker 时会写入 files: []，永久丢失已持久化的 etag/canonical_url/expected_total_bytes/download_path 等恢复元数据，因此拖越久越难恢复。不建议依赖“手动改 marker 后重启”这类未验证操作。

问题场景

在 InvokeAI 中安装多文件模型（例如 Hugging Face diffusers 模型）时，第一个文件只下载了一部分就退出应用，install tmpdir 中写入了带逐文件恢复元数据的 install marker。之后再次启动应用并恢复该安装时，服务器对该文件的 Range 请求返回 416，导致该 part 在任何 started 信号发出之前就被暂停，整个 install 进入 PAUSED。此时触发 UI 中的 restart 操作，任务不会被重新入队，永远卡在 PAUSED。

报错原文

Resume refused by server. Restart required.
Restored install that pauses before its first download-started signal cannot be restarted (restart_failed no-ops, marker loses resume metadata)

原因分析

可能原因（Issue 正文给出的机制分析）：

install_job.download_parts 只由 _download_started_callback（model_install_default.py:1453）填充。经 _restore_incomplete_installs（model_install_default.py:214）恢复的 install，其 download_parts 初始为空，marker 中的文件元数据被放进 job._resume_metadata。
416 resume-mismatch 分支在 _do_download（download_default.py:434-453）中会在 _signal_job_started 之前暂停并抛错。因此恢复安装的第一个 part 若命中该分支，started 回调永远不会触发，install job 的 download_parts 始终为空。
_download_cancelled_callback 能正确检测 resume_required（在 multifile job 的 parts 上，model_install_default.py:1498）并把 install 置为 PAUSED。
但 restart_failed() 读取的是 install job 的 download_parts（model_install_default.py:625），为空则提前返回，导致 UI 的 restart 无任何动作。
叠加问题：PAUSED 时重写 marker（_write_install_marker，gate 在 model_install_default.py:142）会写入 files: []，丢弃后续 restore/resume 所需的恢复元数据。

环境排查

确认 InvokeAI 版本，检查是否已包含对该 Issue 的修复（Issue 已标记 Fixed）。
确认触发场景是否为多文件安装（multifile install），而非单文件下载。
检查 install tmpdir 中是否存在 install marker，以及其 files 字段是否已变为 []。
检查恢复任务时的服务器响应：是否为 416，且 Content-Range 是否与本地 .downloading 文件不匹配。
Issue 未提供 Python、CUDA、PyTorch、显卡、节点或依赖版本信息，无需据此排查。

解决步骤

升级到包含该修复的 InvokeAI 版本（Issue 已由维护者标记 Fixed）。
若当前版本尚未包含修复，可按 Issue 复现步骤先确认命中路径：启动多文件安装，让第一个文件下载到一半后退出应用；应用停止期间向 tmpdir 中第一个 .downloading 文件追加若干字节垃圾数据，使其比远端文件更大；重启应用并恢复安装。
观察服务端是否返回 416，以及提示是否为 “Resume refused by server. Restart required.”。
触发 restart 动作，观察任务是否立即返回、未入队、保持 PAUSED，且磁盘 marker 中出现 "files": []。
在无修复版本的情况下，按 Issue 说明取消该安装，并从零重新导入模型（re-import from scratch）。

验证方法

修复后，针对恢复且 download_parts 为空的 install job，restart_failed() 应正确回退读取 job._multifile_job.download_parts 并重新入队，使任务不再停在 PAUSED；同时 PAUSED 重写 marker 时不应再把 files 清空为 []，从而保留 etag/canonical_url/expected_total_bytes/download_path 等恢复元数据。Issue 正文中的测试草图可作为验证参考：构造 install_job.download_parts == [] 且 part 设置 resume_required = True 的场景，调用 mm2_installer.restart_failed(install_job)，确认任务被重新入队而非静默 no-op。