feat(desktop): check for updates when the window regains focus by jackwener · Pull Request #2461 · apache/maka

jackwener · 2026-08-07T17:25:36Z

task #162。owner 反馈「自动升级不会及时出现」。

为什么

检查本身没坏，节奏不对：启动 10 秒查一次，之后每 4 小时一次。应用一直开着跨过一次发布，就得等下一个 4 小时刻度才发现——这就是「不及时」的真身。

窗口重新聚焦是个免费信号，而且含义正好：用户回来了。既是发现新版本最有价值的时刻，也是重启提示最不打扰的时刻。

规格六条的落法

触发点：app.on('browser-window-focus')（在 app-lifecycle.ts 里，紧挨 updateService.start()）。多窗口触发同一事件也无所谓，被节流吃掉。
节流 15 分钟，且只有一处记录：lastCheckStartedAt 由真正发起检查的那条路径写入，定时和聚焦共用。按触发路径各记各的会让聚焦检查在定时检查后几秒又发一次——这正是规格点名要避免的。
4 小时兜底保留，聚焦不重置定时：两条触发独立，靠共享节流去重（采纳规格里"不重置更简单"的判断）。
重入保护沿用不绕开：checkForUpdatesOnFocus 走既有 checkForUpdates()，不传 allowDuringDownload——正在下载就是更新已经在来的路上，此时重查正是那个守卫存在的理由。
测试：新增 5 条（clock.now 注入时间源）。
无 UI、无 copy 变更，纯 main 侧。

怎么验证的

新增 5 条单测：聚焦触发一次；节流窗口内（15min − 1ms）不重复；跨过窗口后再查；start() 之前不查；dispose() 之后不查。
故障注入：把节流判断整段拆掉 → 恰好 1 条失败（窗口内重复那条）→ 装回全绿。
@maka/desktop1804 passed / 0 failed；typecheck / lint / format 全绿。
按范围化测试规矩，只跑了 desktop 这一个 workspace。

一处实现说明

clock 依赖原本只有 setTimeout / clearTimeout，节流需要时间源，所以加了可选的 now?()，默认 Date.now。沿用既有 DI 结构，没有引入新的注入机制。

The updater checked once ten seconds after launch and then every four hours. An app left open across a release therefore learned about it whenever the next tick happened to land, which is what "the update does not show up in time" was — the checks were working, the rhythm was wrong. Focus is the signal that costs nothing and means the user is here: it is both when a new version is worth discovering and when a restart prompt is least disruptive. The four-hour timer stays as the floor for a window nobody comes back to, and the two triggers stay independent — a focus check deliberately does not reset the schedule, because the shared throttle already stops them doubling up. The throttle is the point. Focus fires constantly, so one shared `lastCheckStartedAt` is recorded by whichever path actually starts a check, and a focus check inside 15 minutes of the previous one does nothing. Recording it per-trigger would let a focus check fire seconds after a scheduled one. Nothing else moves: silent download and the task-aware install gate are untouched, and the existing in-flight guards are reused rather than bypassed. Behaviour is unchanged in an unpackaged build, before start(), and after dispose().

jackwener · 2026-08-07T17:42:48Z

Review by maka-审美专家 — 通过：聚焦触发更新检查 + 15 分钟节流落地——「谁真发起谁写 lastCheckAt」的单处记录实现正确；不传 allowDuringDownload 的守卫目的论证成立（下载中重查违背守卫存在的理由）；5 条单测覆盖含 start 前/dispose 后边界，故障注入验证节流会咬。首轮 e2e 失败判 flake 双证据齐：update service 有 isPackaged 守卫、e2e 未打包环境聚焦触发为空操作（因果路径为零）+ 重跑全绿。CI 11 项 pass。合入。

jackwener · 2026-08-07T17:25:36Z

task #162。owner 反馈「自动升级不会及时出现」。

为什么

检查本身没坏，节奏不对：启动 10 秒查一次，之后每 4 小时一次。应用一直开着跨过一次发布，就得等下一个 4 小时刻度才发现——这就是「不及时」的真身。

窗口重新聚焦是个免费信号，而且含义正好：用户回来了。既是发现新版本最有价值的时刻，也是重启提示最不打扰的时刻。

规格六条的落法

触发点：app.on('browser-window-focus')（在 app-lifecycle.ts 里，紧挨 updateService.start()）。多窗口触发同一事件也无所谓，被节流吃掉。
节流 15 分钟，且只有一处记录：lastCheckStartedAt 由真正发起检查的那条路径写入，定时和聚焦共用。按触发路径各记各的会让聚焦检查在定时检查后几秒又发一次——这正是规格点名要避免的。
4 小时兜底保留，聚焦不重置定时：两条触发独立，靠共享节流去重（采纳规格里"不重置更简单"的判断）。
重入保护沿用不绕开：checkForUpdatesOnFocus 走既有 checkForUpdates()，不传 allowDuringDownload——正在下载就是更新已经在来的路上，此时重查正是那个守卫存在的理由。
测试：新增 5 条（clock.now 注入时间源）。
无 UI、无 copy 变更，纯 main 侧。

怎么验证的

新增 5 条单测：聚焦触发一次；节流窗口内（15min − 1ms）不重复；跨过窗口后再查；start() 之前不查；dispose() 之后不查。
故障注入：把节流判断整段拆掉 → 恰好 1 条失败（窗口内重复那条）→ 装回全绿。
@maka/desktop1804 passed / 0 failed；typecheck / lint / format 全绿。
按范围化测试规矩，只跑了 desktop 这一个 workspace。

一处实现说明

clock 依赖原本只有 setTimeout / clearTimeout，节流需要时间源，所以加了可选的 now?()，默认 Date.now。沿用既有 DI 结构，没有引入新的注入机制。

The updater checked once ten seconds after launch and then every four hours. An app left open across a release therefore learned about it whenever the next tick happened to land, which is what "the update does not show up in time" was — the checks were working, the rhythm was wrong. Focus is the signal that costs nothing and means the user is here: it is both when a new version is worth discovering and when a restart prompt is least disruptive. The four-hour timer stays as the floor for a window nobody comes back to, and the two triggers stay independent — a focus check deliberately does not reset the schedule, because the shared throttle already stops them doubling up. The throttle is the point. Focus fires constantly, so one shared `lastCheckStartedAt` is recorded by whichever path actually starts a check, and a focus check inside 15 minutes of the previous one does nothing. Recording it per-trigger would let a focus check fire seconds after a scheduled one. Nothing else moves: silent download and the task-aware install gate are untouched, and the existing in-flight guards are reused rather than bypassed. Behaviour is unchanged in an unpackaged build, before start(), and after dispose().

jackwener · 2026-08-07T17:42:48Z

Review by maka-审美专家 — 通过：聚焦触发更新检查 + 15 分钟节流落地——「谁真发起谁写 lastCheckAt」的单处记录实现正确；不传 allowDuringDownload 的守卫目的论证成立（下载中重查违背守卫存在的理由）；5 条单测覆盖含 start 前/dispose 后边界，故障注入验证节流会咬。首轮 e2e 失败判 flake 双证据齐：update service 有 isPackaged 守卫、e2e 未打包环境聚焦触发为空操作（因果路径为零）+ 重跑全绿。CI 11 项 pass。合入。

jackwener · 2026-08-07T17:25:36Z

task #162。owner 反馈「自动升级不会及时出现」。

为什么

检查本身没坏，节奏不对：启动 10 秒查一次，之后每 4 小时一次。应用一直开着跨过一次发布，就得等下一个 4 小时刻度才发现——这就是「不及时」的真身。

窗口重新聚焦是个免费信号，而且含义正好：用户回来了。既是发现新版本最有价值的时刻，也是重启提示最不打扰的时刻。

规格六条的落法

触发点：app.on('browser-window-focus')（在 app-lifecycle.ts 里，紧挨 updateService.start()）。多窗口触发同一事件也无所谓，被节流吃掉。
节流 15 分钟，且只有一处记录：lastCheckStartedAt 由真正发起检查的那条路径写入，定时和聚焦共用。按触发路径各记各的会让聚焦检查在定时检查后几秒又发一次——这正是规格点名要避免的。
4 小时兜底保留，聚焦不重置定时：两条触发独立，靠共享节流去重（采纳规格里"不重置更简单"的判断）。
重入保护沿用不绕开：checkForUpdatesOnFocus 走既有 checkForUpdates()，不传 allowDuringDownload——正在下载就是更新已经在来的路上，此时重查正是那个守卫存在的理由。
测试：新增 5 条（clock.now 注入时间源）。
无 UI、无 copy 变更，纯 main 侧。

怎么验证的

新增 5 条单测：聚焦触发一次；节流窗口内（15min − 1ms）不重复；跨过窗口后再查；start() 之前不查；dispose() 之后不查。
故障注入：把节流判断整段拆掉 → 恰好 1 条失败（窗口内重复那条）→ 装回全绿。
@maka/desktop1804 passed / 0 failed；typecheck / lint / format 全绿。
按范围化测试规矩，只跑了 desktop 这一个 workspace。

一处实现说明

clock 依赖原本只有 setTimeout / clearTimeout，节流需要时间源，所以加了可选的 now?()，默认 Date.now。沿用既有 DI 结构，没有引入新的注入机制。

The updater checked once ten seconds after launch and then every four hours. An app left open across a release therefore learned about it whenever the next tick happened to land, which is what "the update does not show up in time" was — the checks were working, the rhythm was wrong. Focus is the signal that costs nothing and means the user is here: it is both when a new version is worth discovering and when a restart prompt is least disruptive. The four-hour timer stays as the floor for a window nobody comes back to, and the two triggers stay independent — a focus check deliberately does not reset the schedule, because the shared throttle already stops them doubling up. The throttle is the point. Focus fires constantly, so one shared `lastCheckStartedAt` is recorded by whichever path actually starts a check, and a focus check inside 15 minutes of the previous one does nothing. Recording it per-trigger would let a focus check fire seconds after a scheduled one. Nothing else moves: silent download and the task-aware install gate are untouched, and the existing in-flight guards are reused rather than bypassed. Behaviour is unchanged in an unpackaged build, before start(), and after dispose().

jackwener · 2026-08-07T17:42:48Z

Review by maka-审美专家 — 通过：聚焦触发更新检查 + 15 分钟节流落地——「谁真发起谁写 lastCheckAt」的单处记录实现正确；不传 allowDuringDownload 的守卫目的论证成立（下载中重查违背守卫存在的理由）；5 条单测覆盖含 start 前/dispose 后边界，故障注入验证节流会咬。首轮 e2e 失败判 flake 双证据齐：update service 有 isPackaged 守卫、e2e 未打包环境聚焦触发为空操作（因果路径为零）+ 重跑全绿。CI 11 项 pass。合入。

jackwener · 2026-08-07T17:25:36Z

task #162。owner 反馈「自动升级不会及时出现」。

为什么

检查本身没坏，节奏不对：启动 10 秒查一次，之后每 4 小时一次。应用一直开着跨过一次发布，就得等下一个 4 小时刻度才发现——这就是「不及时」的真身。

窗口重新聚焦是个免费信号，而且含义正好：用户回来了。既是发现新版本最有价值的时刻，也是重启提示最不打扰的时刻。

规格六条的落法

触发点：app.on('browser-window-focus')（在 app-lifecycle.ts 里，紧挨 updateService.start()）。多窗口触发同一事件也无所谓，被节流吃掉。
节流 15 分钟，且只有一处记录：lastCheckStartedAt 由真正发起检查的那条路径写入，定时和聚焦共用。按触发路径各记各的会让聚焦检查在定时检查后几秒又发一次——这正是规格点名要避免的。
4 小时兜底保留，聚焦不重置定时：两条触发独立，靠共享节流去重（采纳规格里"不重置更简单"的判断）。
重入保护沿用不绕开：checkForUpdatesOnFocus 走既有 checkForUpdates()，不传 allowDuringDownload——正在下载就是更新已经在来的路上，此时重查正是那个守卫存在的理由。
测试：新增 5 条（clock.now 注入时间源）。
无 UI、无 copy 变更，纯 main 侧。

怎么验证的

新增 5 条单测：聚焦触发一次；节流窗口内（15min − 1ms）不重复；跨过窗口后再查；start() 之前不查；dispose() 之后不查。
故障注入：把节流判断整段拆掉 → 恰好 1 条失败（窗口内重复那条）→ 装回全绿。
@maka/desktop1804 passed / 0 failed；typecheck / lint / format 全绿。
按范围化测试规矩，只跑了 desktop 这一个 workspace。

一处实现说明

clock 依赖原本只有 setTimeout / clearTimeout，节流需要时间源，所以加了可选的 now?()，默认 Date.now。沿用既有 DI 结构，没有引入新的注入机制。

The updater checked once ten seconds after launch and then every four hours. An app left open across a release therefore learned about it whenever the next tick happened to land, which is what "the update does not show up in time" was — the checks were working, the rhythm was wrong. Focus is the signal that costs nothing and means the user is here: it is both when a new version is worth discovering and when a restart prompt is least disruptive. The four-hour timer stays as the floor for a window nobody comes back to, and the two triggers stay independent — a focus check deliberately does not reset the schedule, because the shared throttle already stops them doubling up. The throttle is the point. Focus fires constantly, so one shared `lastCheckStartedAt` is recorded by whichever path actually starts a check, and a focus check inside 15 minutes of the previous one does nothing. Recording it per-trigger would let a focus check fire seconds after a scheduled one. Nothing else moves: silent download and the task-aware install gate are untouched, and the existing in-flight guards are reused rather than bypassed. Behaviour is unchanged in an unpackaged build, before start(), and after dispose().

jackwener · 2026-08-07T17:42:48Z

Review by maka-审美专家 — 通过：聚焦触发更新检查 + 15 分钟节流落地——「谁真发起谁写 lastCheckAt」的单处记录实现正确；不传 allowDuringDownload 的守卫目的论证成立（下载中重查违背守卫存在的理由）；5 条单测覆盖含 start 前/dispose 后边界，故障注入验证节流会咬。首轮 e2e 失败判 flake 双证据齐：update service 有 isPackaged 守卫、e2e 未打包环境聚焦触发为空操作（因果路径为零）+ 重跑全绿。CI 11 项 pass。合入。

jackwener · 2026-08-07T17:25:36Z

task #162。owner 反馈「自动升级不会及时出现」。

为什么

检查本身没坏，节奏不对：启动 10 秒查一次，之后每 4 小时一次。应用一直开着跨过一次发布，就得等下一个 4 小时刻度才发现——这就是「不及时」的真身。

窗口重新聚焦是个免费信号，而且含义正好：用户回来了。既是发现新版本最有价值的时刻，也是重启提示最不打扰的时刻。

规格六条的落法

触发点：app.on('browser-window-focus')（在 app-lifecycle.ts 里，紧挨 updateService.start()）。多窗口触发同一事件也无所谓，被节流吃掉。
节流 15 分钟，且只有一处记录：lastCheckStartedAt 由真正发起检查的那条路径写入，定时和聚焦共用。按触发路径各记各的会让聚焦检查在定时检查后几秒又发一次——这正是规格点名要避免的。
4 小时兜底保留，聚焦不重置定时：两条触发独立，靠共享节流去重（采纳规格里"不重置更简单"的判断）。
重入保护沿用不绕开：checkForUpdatesOnFocus 走既有 checkForUpdates()，不传 allowDuringDownload——正在下载就是更新已经在来的路上，此时重查正是那个守卫存在的理由。
测试：新增 5 条（clock.now 注入时间源）。
无 UI、无 copy 变更，纯 main 侧。

怎么验证的

新增 5 条单测：聚焦触发一次；节流窗口内（15min − 1ms）不重复；跨过窗口后再查；start() 之前不查；dispose() 之后不查。
故障注入：把节流判断整段拆掉 → 恰好 1 条失败（窗口内重复那条）→ 装回全绿。
@maka/desktop1804 passed / 0 failed；typecheck / lint / format 全绿。
按范围化测试规矩，只跑了 desktop 这一个 workspace。

一处实现说明

clock 依赖原本只有 setTimeout / clearTimeout，节流需要时间源，所以加了可选的 now?()，默认 Date.now。沿用既有 DI 结构，没有引入新的注入机制。

The updater checked once ten seconds after launch and then every four hours. An app left open across a release therefore learned about it whenever the next tick happened to land, which is what "the update does not show up in time" was — the checks were working, the rhythm was wrong. Focus is the signal that costs nothing and means the user is here: it is both when a new version is worth discovering and when a restart prompt is least disruptive. The four-hour timer stays as the floor for a window nobody comes back to, and the two triggers stay independent — a focus check deliberately does not reset the schedule, because the shared throttle already stops them doubling up. The throttle is the point. Focus fires constantly, so one shared `lastCheckStartedAt` is recorded by whichever path actually starts a check, and a focus check inside 15 minutes of the previous one does nothing. Recording it per-trigger would let a focus check fire seconds after a scheduled one. Nothing else moves: silent download and the task-aware install gate are untouched, and the existing in-flight guards are reused rather than bypassed. Behaviour is unchanged in an unpackaged build, before start(), and after dispose().

jackwener · 2026-08-07T17:42:48Z

Review by maka-审美专家 — 通过：聚焦触发更新检查 + 15 分钟节流落地——「谁真发起谁写 lastCheckAt」的单处记录实现正确；不传 allowDuringDownload 的守卫目的论证成立（下载中重查违背守卫存在的理由）；5 条单测覆盖含 start 前/dispose 后边界，故障注入验证节流会咬。首轮 e2e 失败判 flake 双证据齐：update service 有 isPackaged 守卫、e2e 未打包环境聚焦触发为空操作（因果路径为零）+ 重跑全绿。CI 11 项 pass。合入。

jackwener · 2026-08-07T17:25:36Z

task #162。owner 反馈「自动升级不会及时出现」。

为什么

检查本身没坏，节奏不对：启动 10 秒查一次，之后每 4 小时一次。应用一直开着跨过一次发布，就得等下一个 4 小时刻度才发现——这就是「不及时」的真身。

窗口重新聚焦是个免费信号，而且含义正好：用户回来了。既是发现新版本最有价值的时刻，也是重启提示最不打扰的时刻。

规格六条的落法

触发点：app.on('browser-window-focus')（在 app-lifecycle.ts 里，紧挨 updateService.start()）。多窗口触发同一事件也无所谓，被节流吃掉。
节流 15 分钟，且只有一处记录：lastCheckStartedAt 由真正发起检查的那条路径写入，定时和聚焦共用。按触发路径各记各的会让聚焦检查在定时检查后几秒又发一次——这正是规格点名要避免的。
4 小时兜底保留，聚焦不重置定时：两条触发独立，靠共享节流去重（采纳规格里"不重置更简单"的判断）。
重入保护沿用不绕开：checkForUpdatesOnFocus 走既有 checkForUpdates()，不传 allowDuringDownload——正在下载就是更新已经在来的路上，此时重查正是那个守卫存在的理由。
测试：新增 5 条（clock.now 注入时间源）。
无 UI、无 copy 变更，纯 main 侧。

怎么验证的

新增 5 条单测：聚焦触发一次；节流窗口内（15min − 1ms）不重复；跨过窗口后再查；start() 之前不查；dispose() 之后不查。
故障注入：把节流判断整段拆掉 → 恰好 1 条失败（窗口内重复那条）→ 装回全绿。
@maka/desktop1804 passed / 0 failed；typecheck / lint / format 全绿。
按范围化测试规矩，只跑了 desktop 这一个 workspace。

一处实现说明

clock 依赖原本只有 setTimeout / clearTimeout，节流需要时间源，所以加了可选的 now?()，默认 Date.now。沿用既有 DI 结构，没有引入新的注入机制。

The updater checked once ten seconds after launch and then every four hours. An app left open across a release therefore learned about it whenever the next tick happened to land, which is what "the update does not show up in time" was — the checks were working, the rhythm was wrong. Focus is the signal that costs nothing and means the user is here: it is both when a new version is worth discovering and when a restart prompt is least disruptive. The four-hour timer stays as the floor for a window nobody comes back to, and the two triggers stay independent — a focus check deliberately does not reset the schedule, because the shared throttle already stops them doubling up. The throttle is the point. Focus fires constantly, so one shared `lastCheckStartedAt` is recorded by whichever path actually starts a check, and a focus check inside 15 minutes of the previous one does nothing. Recording it per-trigger would let a focus check fire seconds after a scheduled one. Nothing else moves: silent download and the task-aware install gate are untouched, and the existing in-flight guards are reused rather than bypassed. Behaviour is unchanged in an unpackaged build, before start(), and after dispose().

jackwener · 2026-08-07T17:42:48Z

Review by maka-审美专家 — 通过：聚焦触发更新检查 + 15 分钟节流落地——「谁真发起谁写 lastCheckAt」的单处记录实现正确；不传 allowDuringDownload 的守卫目的论证成立（下载中重查违背守卫存在的理由）；5 条单测覆盖含 start 前/dispose 后边界，故障注入验证节流会咬。首轮 e2e 失败判 flake 双证据齐：update service 有 isPackaged 守卫、e2e 未打包环境聚焦触发为空操作（因果路径为零）+ 重跑全绿。CI 11 项 pass。合入。

jackwener · 2026-08-07T17:25:36Z

task #162。owner 反馈「自动升级不会及时出现」。

为什么

检查本身没坏，节奏不对：启动 10 秒查一次，之后每 4 小时一次。应用一直开着跨过一次发布，就得等下一个 4 小时刻度才发现——这就是「不及时」的真身。

窗口重新聚焦是个免费信号，而且含义正好：用户回来了。既是发现新版本最有价值的时刻，也是重启提示最不打扰的时刻。

规格六条的落法

触发点：app.on('browser-window-focus')（在 app-lifecycle.ts 里，紧挨 updateService.start()）。多窗口触发同一事件也无所谓，被节流吃掉。
节流 15 分钟，且只有一处记录：lastCheckStartedAt 由真正发起检查的那条路径写入，定时和聚焦共用。按触发路径各记各的会让聚焦检查在定时检查后几秒又发一次——这正是规格点名要避免的。
4 小时兜底保留，聚焦不重置定时：两条触发独立，靠共享节流去重（采纳规格里"不重置更简单"的判断）。
重入保护沿用不绕开：checkForUpdatesOnFocus 走既有 checkForUpdates()，不传 allowDuringDownload——正在下载就是更新已经在来的路上，此时重查正是那个守卫存在的理由。
测试：新增 5 条（clock.now 注入时间源）。
无 UI、无 copy 变更，纯 main 侧。

怎么验证的

新增 5 条单测：聚焦触发一次；节流窗口内（15min − 1ms）不重复；跨过窗口后再查；start() 之前不查；dispose() 之后不查。
故障注入：把节流判断整段拆掉 → 恰好 1 条失败（窗口内重复那条）→ 装回全绿。
@maka/desktop1804 passed / 0 failed；typecheck / lint / format 全绿。
按范围化测试规矩，只跑了 desktop 这一个 workspace。

一处实现说明

clock 依赖原本只有 setTimeout / clearTimeout，节流需要时间源，所以加了可选的 now?()，默认 Date.now。沿用既有 DI 结构，没有引入新的注入机制。

The updater checked once ten seconds after launch and then every four hours. An app left open across a release therefore learned about it whenever the next tick happened to land, which is what "the update does not show up in time" was — the checks were working, the rhythm was wrong. Focus is the signal that costs nothing and means the user is here: it is both when a new version is worth discovering and when a restart prompt is least disruptive. The four-hour timer stays as the floor for a window nobody comes back to, and the two triggers stay independent — a focus check deliberately does not reset the schedule, because the shared throttle already stops them doubling up. The throttle is the point. Focus fires constantly, so one shared `lastCheckStartedAt` is recorded by whichever path actually starts a check, and a focus check inside 15 minutes of the previous one does nothing. Recording it per-trigger would let a focus check fire seconds after a scheduled one. Nothing else moves: silent download and the task-aware install gate are untouched, and the existing in-flight guards are reused rather than bypassed. Behaviour is unchanged in an unpackaged build, before start(), and after dispose().

jackwener · 2026-08-07T17:42:48Z

Review by maka-审美专家 — 通过：聚焦触发更新检查 + 15 分钟节流落地——「谁真发起谁写 lastCheckAt」的单处记录实现正确；不传 allowDuringDownload 的守卫目的论证成立（下载中重查违背守卫存在的理由）；5 条单测覆盖含 start 前/dispose 后边界，故障注入验证节流会咬。首轮 e2e 失败判 flake 双证据齐：update service 有 isPackaged 守卫、e2e 未打包环境聚焦触发为空操作（因果路径为零）+ 重跑全绿。CI 11 项 pass。合入。

jackwener · 2026-08-07T17:25:36Z

task #162。owner 反馈「自动升级不会及时出现」。

为什么

检查本身没坏，节奏不对：启动 10 秒查一次，之后每 4 小时一次。应用一直开着跨过一次发布，就得等下一个 4 小时刻度才发现——这就是「不及时」的真身。

窗口重新聚焦是个免费信号，而且含义正好：用户回来了。既是发现新版本最有价值的时刻，也是重启提示最不打扰的时刻。

规格六条的落法

触发点：app.on('browser-window-focus')（在 app-lifecycle.ts 里，紧挨 updateService.start()）。多窗口触发同一事件也无所谓，被节流吃掉。
节流 15 分钟，且只有一处记录：lastCheckStartedAt 由真正发起检查的那条路径写入，定时和聚焦共用。按触发路径各记各的会让聚焦检查在定时检查后几秒又发一次——这正是规格点名要避免的。
4 小时兜底保留，聚焦不重置定时：两条触发独立，靠共享节流去重（采纳规格里"不重置更简单"的判断）。
重入保护沿用不绕开：checkForUpdatesOnFocus 走既有 checkForUpdates()，不传 allowDuringDownload——正在下载就是更新已经在来的路上，此时重查正是那个守卫存在的理由。
测试：新增 5 条（clock.now 注入时间源）。
无 UI、无 copy 变更，纯 main 侧。

怎么验证的

新增 5 条单测：聚焦触发一次；节流窗口内（15min − 1ms）不重复；跨过窗口后再查；start() 之前不查；dispose() 之后不查。
故障注入：把节流判断整段拆掉 → 恰好 1 条失败（窗口内重复那条）→ 装回全绿。
@maka/desktop1804 passed / 0 failed；typecheck / lint / format 全绿。
按范围化测试规矩，只跑了 desktop 这一个 workspace。

一处实现说明

clock 依赖原本只有 setTimeout / clearTimeout，节流需要时间源，所以加了可选的 now?()，默认 Date.now。沿用既有 DI 结构，没有引入新的注入机制。

The updater checked once ten seconds after launch and then every four hours. An app left open across a release therefore learned about it whenever the next tick happened to land, which is what "the update does not show up in time" was — the checks were working, the rhythm was wrong. Focus is the signal that costs nothing and means the user is here: it is both when a new version is worth discovering and when a restart prompt is least disruptive. The four-hour timer stays as the floor for a window nobody comes back to, and the two triggers stay independent — a focus check deliberately does not reset the schedule, because the shared throttle already stops them doubling up. The throttle is the point. Focus fires constantly, so one shared `lastCheckStartedAt` is recorded by whichever path actually starts a check, and a focus check inside 15 minutes of the previous one does nothing. Recording it per-trigger would let a focus check fire seconds after a scheduled one. Nothing else moves: silent download and the task-aware install gate are untouched, and the existing in-flight guards are reused rather than bypassed. Behaviour is unchanged in an unpackaged build, before start(), and after dispose().

jackwener · 2026-08-07T17:42:48Z

Review by maka-审美专家 — 通过：聚焦触发更新检查 + 15 分钟节流落地——「谁真发起谁写 lastCheckAt」的单处记录实现正确；不传 allowDuringDownload 的守卫目的论证成立（下载中重查违背守卫存在的理由）；5 条单测覆盖含 start 前/dispose 后边界，故障注入验证节流会咬。首轮 e2e 失败判 flake 双证据齐：update service 有 isPackaged 守卫、e2e 未打包环境聚焦触发为空操作（因果路径为零）+ 重跑全绿。CI 11 项 pass。合入。

jackwener merged commit 6af9ebd into mainAug 7, 2026
21 of 23 checks passed

Uh oh!

Conversation

jackwener commented Aug 7, 2026

为什么

规格六条的落法

怎么验证的

一处实现说明

Uh oh!

jackwener commented Aug 7, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

jackwener commented Aug 7, 2026

为什么

规格六条的落法

怎么验证的

一处实现说明

Uh oh!

jackwener commented Aug 7, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

jackwener commented Aug 7, 2026

为什么

规格六条的落法

怎么验证的

一处实现说明

Uh oh!

jackwener commented Aug 7, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

jackwener commented Aug 7, 2026

为什么

规格六条的落法

怎么验证的

一处实现说明

Uh oh!

jackwener commented Aug 7, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

jackwener commented Aug 7, 2026

为什么