eh-downloader

9 Commits 1 Branch 0 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
toor	9241c5dcd1	fix: 补 panic 兜底，防止将来任何内部错误导致整进程消失上一提交修了并发 map 写的问题（fatal error，不可 recover）。这次给引擎加一层普通 panic 的兜底： - safeRunTask：画廊级别，panic 时把该画廊标记失败 + 记日志 - safeDownloadPage：页级别，一页出错不带走整个 worker - 恢复代码本身再包一层 recover —— 万一 panic 根因就是 store 出问题，恢复逻辑不该二次崩溃逃逸出去这不能替代修 bug（runtime fatal error 依然拦不住），但能保证「将来再出别的内部错误」时用户能看到日志，而不是应用无声消失、已下载的文件也白搭。 TestSafeRunTaskRecoversPanic 验证 recover 生效（该测试在写第一版时还真抓出了恢复代码的二次 panic 隐患）。	2026-10-09 08:41:42 +08:00
toor	27ca6e08a0	fix: 修复大画廊下载时进程静默闪退（fatal error: concurrent map write）现象：点「开始下载」后，单个画廊图片较多时整个程序无报错直接退出。只在图片多的画廊上偶发。根因：pageState.snapshotLocked 用浅拷贝把 Task 交给 UI： t := *s.task // Pages map 仍是同一块内存快照被 EventsEmit 做 JSON 序列化时，其他页 worker 正在写同一个 map，撞上就抛 Go runtime 的致命错误： fatal error: concurrent map iteration and map write 这是 runtime 级 fatal error，不可 recover，直接杀进程 —— 所以没有任何报错提示。图片越多、页并发越高，并发写窗口越长，越容易触发。同一问题还有第二处：Store.UpsertTask 存的是原值（含活的 map），而 Flush() 会在后台 json.Marshal 整个 state，同样会撞上。修复： - snapshotLocked 深拷贝 Pages map 与 FailedList slice - UpsertTask 存前先 clone()，让 store 完全拥有自己的数据 - 另加一个兜底 recover，防止将来再有 panic 直接杀掉进程测试： - TestSnapshotDoesNotSharePagesMap：验证快照隔离（修复前失败） - TestSnapshotRaceWindowClosed：持续写原 task + 持续序列化快照，精准复现崩溃窗口 —— 实测修复前 fatal error 崩进程，修复后通过 - 大画廊压测：200 页 × 页并发 20，以及 5 画廊 × 60 页 × 并发 16 测试从 62 增至 67。	2026-10-09 08:39:27 +08:00

Author

SHA1

Message

Date

toor

9241c5dcd1

fix: 补 panic 兜底，防止将来任何内部错误导致整进程消失

上一提交修了并发 map 写的问题（fatal error，不可 recover）。
这次给引擎加一层普通 panic 的兜底：

- safeRunTask：画廊级别，panic 时把该画廊标记失败 + 记日志
- safeDownloadPage：页级别，一页出错不带走整个 worker
- 恢复代码本身再包一层 recover —— 万一 panic 根因就是 store 出问题，
  恢复逻辑不该二次崩溃逃逸出去

这不能替代修 bug（runtime fatal error 依然拦不住），
但能保证「将来再出别的内部错误」时用户能看到日志，
而不是应用无声消失、已下载的文件也白搭。

TestSafeRunTaskRecoversPanic 验证 recover 生效
（该测试在写第一版时还真抓出了恢复代码的二次 panic 隐患）。

2026-10-09 08:41:42 +08:00

toor

27ca6e08a0

fix: 修复大画廊下载时进程静默闪退（fatal error: concurrent map write）

现象：点「开始下载」后，单个画廊图片较多时整个程序无报错直接退出。
只在图片多的画廊上偶发。

根因：pageState.snapshotLocked 用浅拷贝把 Task 交给 UI：
    t := *s.task          // Pages map 仍是同一块内存
快照被 EventsEmit 做 JSON 序列化时，其他页 worker 正在写同一个 map，
撞上就抛 Go runtime 的致命错误：

    fatal error: concurrent map iteration and map write

这是 runtime 级 fatal error，不可 recover，直接杀进程 —— 所以没有任何
报错提示。图片越多、页并发越高，并发写窗口越长，越容易触发。

同一问题还有第二处：Store.UpsertTask 存的是原值（含活的 map），
而 Flush() 会在后台 json.Marshal 整个 state，同样会撞上。

修复：
- snapshotLocked 深拷贝 Pages map 与 FailedList slice
- UpsertTask 存前先 clone()，让 store 完全拥有自己的数据
- 另加一个兜底 recover，防止将来再有 panic 直接杀掉进程

测试：
- TestSnapshotDoesNotSharePagesMap：验证快照隔离（修复前失败）
- TestSnapshotRaceWindowClosed：持续写原 task + 持续序列化快照，
  精准复现崩溃窗口 —— 实测修复前 fatal error 崩进程，修复后通过
- 大画廊压测：200 页 × 页并发 20，以及 5 画廊 × 60 页 × 并发 16

测试从 62 增至 67。

2026-10-09 08:39:27 +08:00