fix: prevent intermittent Model Plans load failures

[devRickyyy]

Summary

The Model Plans settings can intermittently fail to load and show the red toast 暂时无法加载模型方案.

When this happens, the configured model plans are not displayed and the user cannot manage them from Settings.

Steps to Reproduce

The issue is intermittent and does not yet have a deterministic trigger.

1. Open Settings > Model Plans.
2. Navigate away, reopen the panel, switch workspaces, or restart Tutti.
3. Repeat until the model-plan list fails to load.

Expected Behavior

• Model Plans load successfully whenever the settings surface is opened.
• Existing configured plans remain visible and manageable.
• Reopening Settings, switching workspaces, or restarting Tutti does not produce a spurious load-failure toast.

Actual Behavior

• The Model Plans surface occasionally fails to populate.
• Tutti shows 暂时无法加载模型方案.
• The user must leave the surface and try again, and the failure may recur.

Acceptance Criteria

• Identify and fix the intermittent Model Plans loading failure.
• Opening and revisiting Model Plans reliably displays the configured plans.
• Workspace switching and normal application restarts do not trigger the failure.
• The 暂时无法加载模型方案 toast no longer appears for this intermittent case.
• Add regression coverage for the failure path once identified.

Environment

• OS: macOS
• Surface: Desktop Settings > Model Plans
• Current project checkout inspected: cfc997347ff4

[llwx2324]

当前状态

目前我还没有稳定复现该问题，也尚未发起 PR。

一开始，我在本地实现了一版针对 renderer 过期刷新请求的隔离补丁。但重新阅读 Issue 并完整检查请求链路后，我认为这份补丁虽然修复了一类真实存在的异步状态问题，却还不能证明它解决了本 Issue 中 listModelPlans 间歇性失败的根因。

因此，我暂时没有把该补丁作为最终修复提交，以免把候选假设误报为已经确认的根因。

排查路径

我从 Settings 的入口开始，沿 renderer、HTTP client、daemon API、service 和 SQLite store 完整跟踪了 Model Plans 的加载链路：

WorkspaceSettingsService.openPanel() / selectSection()
  -> refreshActiveSettingsSurface()
  -> refreshModelPlansSurface()
  -> WorkspaceModelPlansController.refreshPlans()
  -> DesktopWorkspaceSettingsClient.listModelPlans()
  -> requestDaemon() / fetch()
  -> GET /v1/workspaces/{workspaceID}/model-plans
  -> DaemonAPI.ListModelPlans()
  -> modelplan.Service.ListPlans()
  -> SQLiteStore.ListModelPlans()

主要阅读了以下文件：

• workspaceSettingsService.ts
  • Settings 打开和重新打开
  • section 切换
  • workspace 同步和 controller reset
• workspaceSettingsStore.ts
  • modelPlans 状态对象的生命周期及替换逻辑
• workspaceModelPlansController.ts
  • loading 拦截
  • Plans 刷新、toast、finally 和引用计数刷新
• workspaceModelPlansController.test.ts
  • 现有测试设施和引用计数异步测试
• desktopWorkspaceSettingsClient.ts
  • Model Plans 的原始 HTTP 调用和错误处理
• registerWorkspaceWorkbenchServices.ts
  • Settings client 和标准 TuttidClient 的装配方式
• createDesktopTuttidClient.ts / createRestartAwareFetch.ts
  • 标准的 daemon transport 和请求失败诊断
• services/tuttid/api/daemon_model_plans.go
  • Model Plans HTTP 响应路径
• services/tuttid/service/modelplan/service.go
  • service 层的列表读取逻辑
• services/tuttid/data/workspace/sqlite_model_plans.go
  • SQLite 查询、凭据解密和 JSON 解析
• 当前可用的 Desktop 与 daemon 日志

目前的发现

1. loading 拦截本身不能完整解释这个问题

在同一份 state 中，原代码会阻止第一个请求尚未完成时发起第二次刷新：

if (!workspaceID || this.state.loading) {
  return;
}

因此，仅仅重新打开同一个 Settings 页面时，不会自然形成“请求 A 发出、请求 B 发出、A 最后覆盖 B”的时序，因为 B 通常会被 loading 直接拦截。

但是，切换 workspace 时会调用 reset()，替换整个 modelPlans state。新 state 的初始值又是 loading: false，因此 workspace A 的旧请求和 workspace B 的新请求仍然可能同时处于未完成状态。

我也修正了之前对下面这条赋值语句的理解：

this.state.plans = await client.listModelPlans(workspaceID);

该赋值语句左侧的属性引用会在等待右侧 Promise 之前求值。因此，一个过期的成功请求并不一定会直接把结果写入新创建的 state。

目前更明确的过期副作用是 await 之后对当前 this.state 的再次访问，例如：

• 旧请求失败后无条件显示错误 toast
• 旧请求的 finally 清除当前 state 的 loading
• workspace 或 state 已经改变后，继续启动后续工作

这些属于 workspace 切换场景下真实存在的正确性风险，但它们仍然不能解释最初的请求为什么会失败。

此外，loading 拦截还可能放大一次真实的请求失败：旧请求仍在进行时，用户重新打开 Settings 并不会产生一次新的请求，因此新打开的页面仍然依赖原来的旧请求。

2. 出现 toast 说明列表 Promise 确实发生了失败

暂时无法加载模型方案 是在 listModelPlans 外层的 catch 中显示的。

renderer 竞态可以导致一个已经过期的失败在错误的时间显示，但它不会凭空制造底层的 fetch、HTTP 或响应解析错误。

另外，正常的完整应用重启会销毁之前的 renderer 及其中的 Promise。因此，如果问题发生在一个全新进程中，仅靠旧 renderer 请求隔离也无法解释该现象。

这也是我不再认为 renderer fencing 足以完整解决本 Issue 的主要原因。

3. Model Plans 使用了一条独立的原始 transport 路径

相邻的大部分 workspace 操作都使用注入的、由 createRestartAwareFetch() 支持的标准 TuttidClient。

但 desktopWorkspaceSettingsClient.ts 中的 Model Plans 操作仍然通过私有的 requestDaemon() 直接发送请求。

这个原始 helper 每次请求都会重新执行 getBackendConfig()，所以目前没有证据表明它只是缓存了过期的 daemon 地址或 token。

不过，它绕过了标准的 generated client 和 tuttid.http.request_failed 诊断。因此，当前的失败 toast 无法区分实际失败属于哪一种情况：

• fetch、连接或 Abort 错误
• Model Plan service 暂时不可用时返回 HTTP 503
• service 或 store 失败时返回 HTTP 502
• 鉴权或 backend 配置问题
• 响应 JSON 解析失败

4. daemon/store 中的单条错误可能导致整个列表失败

daemon 当前会返回：

• ModelPlanService 不可用时返回 503
• ListPlans 或底层 store 返回错误时返回 502
• 正常情况下返回 200 和 Plans 列表

SQLiteStore.ListModelPlans() 会依次读取该 workspace 的每一条 Model Plan。在扫描过程中，还会解密保存的 API key，并解析 models 和 detection JSON。

因此，如果其中一条记录的凭据无法解密，或者 JSON 数据损坏，整个列表都可能加载失败。

不过这目前仍然只是一个假设。单条持久化数据损坏通常比 Issue 中描述的间歇性失败更加稳定，因此在没有对应 daemon 错误日志之前，我暂时没有沿这个方向直接修改数据或 migration。

探索性补丁

我曾在本地实现一版 latest-wins 隔离方案，主要包括：

• 单调递增的刷新序号
• 捕获请求启动时的 workspace ID 和 state 对象
• reset() 时使在途请求失效
• 过期请求或不可见页面的失败不再显示 toast
• 旧请求不能清除新请求的 loading
• 使用 deferred Promise 人为控制请求完成顺序的测试

目前该分支的 controller 目标测试结果为：

37 tests passed, 0 failed

这些测试能够证明：在人工构造的异步时序下，所设计的请求隔离语义可以正常工作。

但它们不能证明这种时序就是 #2059 的真实根因，也没有解释 listModelPlans 为什么会发生 rejected。因此，我把这份改动保留为探索性补丁，没有直接作为最终修复发起 PR。

当前假设

目前我对可能原因的排序如下。

1. 瞬时 transport 或 daemon 生命周期问题

这是目前最符合“重新打开、切换 workspace 或重启附近间歇发生”这一表现的方向。

需要拿到一次真实失败的请求阶段、HTTP 状态或 fetch 错误，并与相同时间点的 daemon 日志对应起来。

2. renderer 的过期副作用与被丢弃的新刷新

这可以解释：

• workspace 切换后出现无意义的旧请求 toast
• 旧请求提前清除当前 loading
• 用户重新进入页面时，新的刷新意图被 loading 丢弃

它也可能放大一次真实的请求失败，但不能独立解释底层请求为什么失败，也不能完整解释全新进程中的重启场景。

3. daemon/store 中的数据解析或凭据解密失败

该方向可以解释 HTTP 502，以及为什么已配置的 Plans 全部不显示。

但目前没有日志证据，而且如果是固定损坏的数据库记录，通常应该更容易稳定复现。

目前也没有证据表明该问题只会发生在 macOS。renderer 和 daemon 的主要代码路径是跨平台共享的，因此在 Windows 上复现同样有助于缩小范围。

我已经检查了仓库提供的 Windows 隔离 E2E 启动方式，并开始准备 Windows 验证环境，但在期限前没有完成稳定的 GUI 压力复现，所以目前不能得出平台相关结论。

现有的 Windows 开发日志中没有发现 /model-plans 请求失败。只发现过一条其他接口的 Abort 记录，它不足以用于推断本 Issue 的根因。

建议的下一步

在继续修改行为之前，我认为应该先捕获一次能够对失败进行分类的真实证据：

1. 记录 Model Plans 请求的路径、失败阶段、HTTP 状态或 fetch 错误及时间戳，同时避免记录任何凭据
2. 将该请求与相同时间点的 daemon 日志以及 daemon 重启状态关联起来
3. 根据证据继续分支排查：
   • fetch 或连接错误：排查 transport 和 daemon 生命周期
   • HTTP 503：排查 Model Plan service 的初始化和可用状态
   • HTTP 502：继续检查 daemon/service/store 返回的具体错误
   • 请求成功但 UI 状态不正确：回到 renderer 状态归属和请求隔离
4. 在确认失败层级后，在对应模块增加回归测试，并验证原代码下测试失败、最小修复后测试通过

如果有人保留了问题实际发生时的日志包或大致时间点，尤其是同一次运行中的 renderer 和 tuttid 日志，将能够立即缩小排查范围。