[Bug] 启动下载更新补丁后未应用却自动重启客户端

[qsoyq]

问题描述 / What happened

启动 Cindy 桌面端时，客户端会在 Splash 阶段检查并下载更新补丁。补丁下载完成后，客户端会自动重启。

但这次重启发生时，补丁实际上还没有被应用；客户端重启后仍然提示用户“有更新可以应用”，需要再次手动操作。

实际行为：

1. 启动桌面端。
2. 客户端检查到新版本并下载更新补丁。
3. 补丁下载完成后，客户端自动重启。
4. 重启后，更新仍显示为可应用状态。

期望行为：

1. 启动时可以自动检查并下载补丁。
2. 补丁下载完成后继续进入客户端，不应仅因为下载完成而自动重启。
3. 用户点击“应用更新”后，再退出客户端并由更新器替换安装包。
4. 应用完成后重新启动进入新版本，且不再重复提示同一个更新。

环境 / Environment

• Cindy 版本或 commit / version or commit: 0.1.31
• 平台与版本 / platform & OS version: macOS 26.4 arm64
• 安装方式 / install method: macOS 正式打包版本

复现步骤 / Steps to reproduce

1. 使用一个低于 CDN manifest 最新版本的正式版 Cindy。
2. 启动客户端。
3. 等待启动更新流程完成补丁下载。
4. 观察客户端是否在用户确认前自动重启。
5. 重启后观察更新提示状态。

日志与截图 / Logs & screenshots

暂无附件。

源码定位

当前实现已经具备“只下载并暂存补丁”的状态：

• apps/desktop/src/main/updateService.ts 的 doCheckForUpdate() 下载并校验 ZIP 后，将补丁写入 updates/patch-info.json，并把状态设置为 ready。
• 同一文件的 buildStartupReadyReply() 在启动阶段发现补丁 ready 后，直接返回 action: 'relaunch'。
• apps/desktop/src/renderer/contexts/EnvCheckContext.tsx 收到 action: 'relaunch' 后进入 update_done。
• apps/desktop/src/renderer/hooks/useSplash.ts 随后自动调用 autoRelaunchToUpdate()，触发客户端重启和更新器执行。

因此，当前重启不是 Electron 下载补丁所必需的步骤，而是启动更新流程把“下载完成”和“应用更新”合并后的结果。

建议验收标准

• 启动阶段下载并校验补丁后，客户端保持运行。
• 下载完成后显示更新已准备就绪的提示。
• 用户未确认应用更新时，不调用 autoRelaunchToUpdate()。
• 用户明确点击应用更新后，才退出客户端并启动外部更新器。
• 应用成功后，新版本启动且同一补丁不再重复提示。
• 更新下载失败时仍可重试，不因下载状态误触发重启。
• 覆盖 macOS 与 Windows 的启动下载、手动应用和重启后状态恢复。

[dash-s-cindy]

判断：该 Issue 的“启动下载完成后自动重启”现象在当前源码快照中成立，但“补丁未应用却自动重启”的根因尚未被证实，整体判断为部分准确。关键证据是：updateService.ts 会在启动阶段发现 ready 补丁后返回 action: 'relaunch'，useSplash.ts 随后调用 autoRelaunchToUpdate()；但仓库已有 patch-info.json、applyAttempts、版本匹配清理以及 macOS/Windows updater 流程，用于处理补丁应用和重启后的状态恢复。Issue 未提供日志或截图，因此目前不能断定 updater 未执行替换。

还有一个重要边界：自动应用受 autoRelaunchOnIdle 控制，默认值为 false。只有用户启用该设置时，启动阶段才会自动 relaunch。因此，“所有启动下载都会自动重启”并不适用于默认配置。

行动：建议先使用 0.1.31 正式签名包、macOS arm64，分别在 autoRelaunchOnIdle=false 和 true 下复现，并收集完整 updater 日志；暂不直接改成“启动只下载、永不自动应用”。后者会移除当前已有且有测试覆盖的自动更新行为，属于需要产品确认的策略变更。如果确认是 updater 替换失败，应修复平台应用链路；如果实际行为符合当前策略但产品不希望启动自动应用，再单独评审并调整启动策略。

源码证据

• apps/desktop/src/main/updateService.ts 的 doCheckForUpdate() 在下载并校验 ZIP 后写入 updates/patch-info.json，并将状态设为 ready。
• 同文件的 buildStartupReadyReply() 在自动更新未禁用、非开发环境且补丁 ready 时返回 action: 'relaunch'。相关注释明确说明，启动时立即应用 staged patch 是当前保留的历史行为。
• apps/desktop/src/renderer/contexts/EnvCheckContext.tsx 在收到 hasUpdate && action === 'relaunch' 后进入 update_done。
• apps/desktop/src/renderer/hooks/useSplash.ts 在 update_done 阶段展示提示后调用 autoRelaunchToUpdate()；主进程在实际 apply boundary 仍会重新检查自动更新开关，被延期时会返回正常启动流程。
• 手动应用入口已经存在：apps/desktop/src/renderer/components/sidebar/UpdateBanner.tsx 的 ready 状态提供 Relaunch to apply，通过 relaunchToUpdate() 启动 updater。因此代码并非缺少“手动应用更新”的能力。
• checkExistingPatch() 会检查补丁文件是否存在；若补丁版本等于当前应用版本，会清理 ZIP 和 patch-info.json；applyAttempts 达到 3 次后会放弃该补丁，以避免无限重启循环。
• apps/desktop/src/main/auto-update-settings-store.ts 将 autoRelaunchOnIdle 默认设为 false，并明确说明：应用仍可自动检查和下载更新，但只有开启该设置后才允许通过 relaunch 自动应用更新。

历史与测试证据

• apps/desktop/src/main/__tests__/updateService.test.ts 已覆盖并锁定以下行为：自动更新开启时，启动阶段 ready 补丁返回 action: 'relaunch'；自动更新关闭时保留补丁并返回 action: 'none'；实际应用前会再次检查设置。
• apps/desktop/src/renderer/hooks/__tests__/useSplashAutoRelaunch.test.tsx 覆盖了启动 relaunch、主进程延期后的恢复，以及启动页至少展示 3 秒的约束。
• PR #1197 和 PR #765 近期都将“下载后自动 relaunch / 手动 relaunch”视为既有产品语义，且明确未修改 updater 的实际退出、重启和应用逻辑。

建议验证矩阵

1. macOS arm64 正式包：
   • 关闭自动应用：启动下载后进入主界面，UpdateBanner 显示 ready，不应自动 relaunch；点击应用更新后确认版本切换。
   • 开启自动应用：确认启动阶段自动 relaunch，并记录 cindy-update.log 中的 pre-update stat、脚本结果、退出码以及重启后的 app.getVersion()。
2. Windows 正式包：覆盖自动应用关闭/开启、手动应用、updater 替换失败和重启后状态恢复。
3. 下载或校验失败：确认保持可重试状态，不调用 autoRelaunchToUpdate()。
4. 若重现“自动重启但版本未变”：同时保存重启前后的 app.getVersion()、updates/patch-info.json、补丁 ZIP 文件名/hash、applyAttempts 及平台 updater 日志。

在获得这些证据前，不能把问题归因于“下载完成错误地触发重启”。

待产品确认：是否保留“启动时自动应用已下载补丁”。当前实现和测试支持该行为，但默认设置关闭；若产品决定取消，应作为明确的产品策略变更处理，而不是直接将 Issue 中的建议视为既定修复方案。

[qsoyq]

补充修正：本 Issue 描述的问题发生在「空闲时自动安装更新」开关关闭的情况下。

在该设置下，补丁下载完成后应保持就绪状态，不得由更新流程自动重启客户端；只有用户主动点击「应用更新」后，才应触发用于应用补丁的重启。

本 Issue 不涉及取消开关开启时的自动安装行为。“重启后补丁仍未应用”作为伴随异常，仍需结合 updater 日志进一步确认原因。

[qsoyq]

进一步澄清现象：这里所说的“重启”发生在启动 Splash 阶段。补丁下载完成后，客户端尚未进入主界面，就出现了一次退出/重新启动的过程；重启后的这次启动才进入主界面，并在左下角显示「应用更新」提示。

因此，本 Issue 描述的并不是“进入主界面后用户点击应用更新导致重启”。「空闲时自动安装更新」开关关闭这一前提保持不变。当前还需要结合 main-2026-08-05.log 和 cindy-update.log 区分这是真实的主进程/updater 重启，还是 Splash/renderer 的状态切换。

[qsoyq]

补充说明（进一步修正“重启”的表述）：

这里所说的“重启”是用户在启动 Splash 阶段观察到的现象：补丁下载完成后，客户端尚未进入主界面，就先出现一次类似退出/重新启动的过程；随后这次启动才进入主界面，并在左下角显示“应用更新”提示。

目前仅凭现有日志，还不能确认这是否是 Cindy 主进程或 updater 的真实退出、重启，也不能排除 Splash/renderer 的组件切换或状态重置。因此，本 Issue 要定位的是：在“空闲时自动安装更新”开关关闭时，下载完成后的启动流程为何在进入主界面前触发该现象。这里不应理解为用户进入主界面后点击“应用更新”才触发的重启。

[fatwang2]

补充一组 updater 日志证据，正好回应上面「未提供日志，不能断定 updater 未执行替换」这一点：在我这台机器上可以确认 updater 确实没有执行替换，而且是稳定复现，不是偶发。

环境：0.1.45 → 0.1.46，macOS arm64（Mac mini），正式签名包，安装在 /Applications/Cindy.app。

现象：连续三次 relaunch，版本原地不动

15:45:25  === App started === v0.1.45
15:45:29  Startup: current=0.1.45, latest=0.1.46
15:45:29  Update available: 0.1.45 → 0.1.46 (wasReady=false)
15:45:50  Startup download result: ready   (226995495 bytes, SHA 校验通过)
15:45:52  auto relaunch conditions met (startup-apply-boundary), applying update v0.1.46
15:45:52  applyAttempts incremented to 1 for v0.1.46
15:45:52  forceQuit() — destroying windows and exiting
15:45:55  === App started === v0.1.45     ← 版本没变
15:45:58  Local patch v0.1.46 matches latest, requesting relaunch
15:46:01  applyAttempts incremented to 2 for v0.1.46
15:46:23  === App started === v0.1.45     ← 还是没变
15:46:29  applyAttempts incremented to 3 for v0.1.46
15:48:13  === App started === v0.1.46     ← 手动下载 DMG 覆盖安装后才上去

循环的成因是闭合的：bundle 没被替换 → 每次启动都判定「本地补丁 v0.1.46 == 线上最新」→ 再次 relaunch，直到 updateService.ts 里 applyAttempts >= 3 兜底才停。用户视角就是「客户端自己反复重启，装不上」。

根因：macOS 更新脚本三次都停在同一行

cindy-update.log 里三次尝试的记录完全一致，都只有开头两三行：

[Thu Aug 13 15:45:52 CST 2026] Update script started, waiting for PID 50636
[Thu Aug 13 15:45:52 CST 2026] target app="/Applications/Cindy.app" appName="Cindy"
[Thu Aug 13 15:45:53 CST 2026] Process 50636 exited, waiting for filesystem to settle
                                                    ← 到此为止，没有下文

按 apps/desktop/src/main/updateScriptMacOS.ts 生成的脚本顺序，这行之后应该依次是 sleep 2 → 写 .updating 锁 → Extracting: ditto -x -k ... → Removing old app → Moving new app into place → open → PROCESS VERIFIED → Cleanup done。一条都没有，说明脚本死在 Process exited 与 ditto 之间那两秒的窗口里。

三个旁证互相印证：

1. 脚本文件残留：$TMPDIR/xdt-maker-update-*.sh 三个都还在（脚本最后一行是 rm -f "$scriptPath" 自删，跑完不该留下）；
2. 解压目录不存在：$TMPDIR/xdt-maker-update-*/ 一个都没有，ditto 从未执行；
3. bundle 从未被动过：三次尝试的 pre-update stat: app mtime=2026-08-12T01:50:43.000Z 完全一致。

不是偶发：8-09 之后就没成功过

翻同一份 cindy-update.log 的历史记录，断点完全相同：

日期	尝试次数	结果
8-09	1	✅ 完整走完 Extracting → mv → open → PROCESS VERIFIED → Cleanup done
8-11	5	❌ 全部停在 waiting for filesystem to settle
8-12	2	❌ 同上
8-13	3	❌ 同上

最后一次成功应用是 8 月 9 日。之后每一次「自动更新」实际都是白下 226MB + 一轮无效重启。

与原报告场景的一处差异

原报告强调「空闲时自动安装更新」开关关闭时仍自动重启。我这边日志是 auto relaunch conditions met (startup-apply-boundary)，走的是开关生效的路径。所以这条评论补充的是根因侧（updater 替换失败），开关侧的策略问题仍以原报告为准，两者建议分开看。

还没查明的部分

每次 forceQuit() 之后约 3 秒就有一个新实例起来（15:45:52.5 退出 → 15:45:55.8 启动）。脚本此时还没走到 open，代码里也没有 app.relaunch()，系统里没有 Cindy 的 LaunchAgent，所以是谁拉起的这个新实例我没能从日志里断定。它是否与脚本中途死亡互为因果（例如新实例启动抢占，或反过来脚本被牵连清理），需要在脚本里补日志复现才能定性。

顺带一个观察：脚本是 spawn('/bin/bash', [scriptPath], { detached: true, stdio: 'ignore' }).unref() 起的，它确实活过了父进程退出（打出了 Process exited 那行），却没能活过紧接着的 sleep 2。这个存活窗口的边界值得单独确认。

按 docs/dev-rules/cindy-updater.md，更新链路改动需要先与维护者确认，所以这里只交证据、不提改法。需要更完整的原始日志（main-*.log + cindy-update.log 全量）可以再说。