[Bug] 有限处理 429 / 插件限流

[phamy]

What happened? / 问题描述

能否有限处理下429的插件问题？

Steps to reproduce / 复现步骤

无

Expected behavior / 预期行为

无

Actual behavior / 实际行为

无

App version / 应用版本

0.14.6

Operating system / 操作系统

Windows

Extra environment / 其他环境信息

PI-Desktop 0.14.6 · win32 x64 · protocol 11 · host 0.14.6

Logs / 日志

Screenshots / 截图

No response

[vastsa]

当前信息不足以单独跟一条缺陷：没有插件 id、复现步骤和日志。

供应商 429 / 限流已由运行时最多 10 次自动重试覆盖（0.14.6，见 #184）。若指的是某个具体插件自己的 429，请补充插件 id 和日志；否则这条会因无法核验而保持开放。

[vastsa]

按 origin/main @ 8fff510a 核了一遍，先把事实摆清楚：这条目前不足以作为可修缺陷（缺插件 id 与日志），但核的过程中确实找到一处值得单独讨论的真实缺口。

已核实：供应商侧 429 是被处理了的

事实	证据
重试上限确实是 10（即首次请求 + 10 次重试 = 11 次尝试）	packages/shared/src/provider-retry.ts:2 PROVIDER_RETRY_MAX_RETRIES = 10；packages/agent-runtime/src/provider-retry.ts:18 PROVIDER_RATE_LIMIT_MAX_RETRIES = PROVIDER_RETRY_MAX_RETRIES；规格同口径：docs/spec/03-runtime/02-agent-runtime.md:162、:188「eleven provider attempts total」
退避 + 尊重 Retry-After	provider-retry.ts 起步 2s、带 jitter、上限 30s，解析 retry-after-ms / retry-after；响应头捕获接线在 runtime.ts
重试在 UI 上可见	重试气泡（ActivityGroup.tsx）+ 本地化文案
插件发起的 provider 调用同样吃这套重试	apps/desktop/electron/main/services/plugin-services.ts:383 的 completeOneShot(...) → packages/agent-runtime/src/one-shot-complete.ts 使用同一个 PROVIDER_RATE_LIMIT_MAX_RETRIES
宿主对插件的刹车是调用配额，不是按次退避	apps/desktop/electron/main/plugin-runtime.ts:575 MAX_COMPLETES_PER_WINDOW = 8（60 秒滚动窗口，超限返回 RATE_LIMITED）

所以维护者当时那句「供应商 429 已由最多 10 次自动重试覆盖（见 #184）」是准确的，#184 也已关闭。

核出来的真实缺口：插件自己的网络请求

如果问题指的是插件用 net.fetch 自己打上游、而那个上游返回 429，那么这条路径不会被重试：

// apps/desktop/electron/main/plugin-runtime.ts:5099
return { status: res.status, headers, bodyText };

429 连同响应头和正文本样交回给插件，宿主不重试、不退避，只受上面那条调用配额约束。这可能是有意设计（重试属于插件自己的策略），也可能是当时漏掉的 —— 但从代码看，它与「插件发起的 provider 调用已受 10 次重试保护」是不对称的。

需要你补充的信息（只要有其中任意两条就能判定）

1. 插件 id（哪个插件触发的）；
2. 日志片段：是从 ~/.pi-desktop/logs/app/session.log 还是插件自己的日志里看到的 429；
3. 这个 429 是供应商返回给插件的，还是插件自己打的上游返回的；
4. 期望行为是什么：宿主替插件自动重试？还是只是希望在 UI 上更明确地看到限流？

如果确认是插件网络路径，我的倾向

不建议在宿主里给 net.fetch 加「无脑重试」：插件可能自己在重试，宿主再套一层会放大请求量，也可能重复非幂等操作。更合适的做法是二选一：

• 只做可观测性：把 429 连同 Retry-After 在插件调用审计里显式标出来，让作者和用户都能看到是限流而不是网络错误；
• 或者提供显式能力：给插件一个可选的 retryOnRateLimit 请求参数，由宿主按 Retry-After 退避重试，默认关闭。

放在 SDK 契约里的东西需要向后兼容，所以想先确认方向再动手，这条保持 open。