调度台状态写入 sessionStorage 超限，疑似导致前端崩溃/异常退出

[qiyinxi]

问题描述

用户反馈 AUTO-MAS 在使用过程中出现崩溃/异常退出。日志显示崩溃前前端持续报错，调度台状态写入 sessionStorage 失败：

Failed to execute 'setItem' on 'Storage': Setting the value of 'scheduler-tabs-session' exceeded the quota.

环境信息

• AUTO-MAS 版本：v5.3.1
• 平台：Windows
• Electron 版本：37.10.3
• Node 版本：22.21.1
• 日志来源：logs-2026-06-18

日志现象

• frontend.log 中 scheduler-tabs-session 配额超限错误共出现 1219 次。
• 首次出现时间：2026-06-12 13:30:53
• 崩溃前最后出现时间：2026-06-18 12:20:02
• 随后前端日志中断，至 2026-06-18 12:27:25 出现应用重新启动记录。
• app.log 中 2026-06-18 12:27:27 后端重新启动，版本为 v5.3.1。
• 对应时间点未看到明确的后端致命 traceback，问题更偏向前端 renderer 或 Electron 侧异常。

初步分析

前端调度台逻辑会将完整 SchedulerTab[] 保存到 sessionStorage，键名为 scheduler-tabs-session。

但 SchedulerTab 中包含 logs、taskQueue、userQueue 等会随任务运行持续增长的数据。同时调度台使用 deep: true watcher 监听整个 tabs 对象，任务运行期间日志、队列、状态变化会频繁触发整份状态序列化和保存。

当调度台数据累积到一定规模后，JSON.stringify(tabs) 超过浏览器 storage 配额，导致 sessionStorage.setItem 持续失败并刷屏报错。虽然该异常当前被 catch，但高频序列化、写入失败和日志输出可能造成 renderer 卡顿、内存/IO 压力升高，最终表现为应用崩溃或异常退出。

期望行为

调度台刷新恢复功能不应保存完整运行期日志/队列大对象；即使 storage 超限，也不应持续刷屏或影响应用稳定性。

建议方向

• sessionStorage 只保存必要的轻量状态，例如 tab key、title、selectedMode、selectedTaskId、状态摘要等。
• 不保存完整 logs、大队列、运行中临时字段。
• 对保存逻辑加节流/防抖，避免 deep watcher 高频序列化整份状态。
• storage 写入失败后降级处理，例如清理旧状态、停止重复写入、提示刷新恢复状态已失效。

logs-2026-06-18.zip