​定时任务的红色感叹号为什么去不掉？一次排障复盘#WorkBuddy

侧栏里几条定时任务顶着红色感叹号，点进去、"解决"、关掉提示横幅，返回列表——叹号还在，纹丝不动。

只要任务失败过一次，它旁边就会挂上这个标记，怎么点都去不掉。我花了点时间，把它从"看起来像 bug"定位到"其实是产品机制"，过程记录如下。

现象

侧栏里 7 条正常启用（ACTIVE）的定时任务，每条旁边都顶着红叹号。点开任意一条，按界面提示处理错误、关掉横幅，回到列表，叹号照旧。给人的观感是：任务坏了，而且一直没修好。

叹号读的是哪个字段

既然是本地客户端，数据总得有个落点。我直接翻了本地的 workbuddy.db，在 automation_runtime_state 表里找到 last_error 字段。

机制就清楚了：

• 任务运行失败（被限流 rate-limited、请求被拒 request-refused、中断 interrupted 等），平台把错误信息写进 last_error；
• 侧栏列表看这个字段空不空，决定要不要画红叹号；
• 而清空 last_error 的唯一路径，是这条任务下一次成功运行——运行结果把这一列覆盖成 NULL。

我又翻了客户端安装包确认：里面没有任何"忽略 / 已读 / 清除错误"的接口。界面上那个"解决"，只是把这一次会话的提示横幅收起来，不写回数据库。只要这条任务最近一次运行是失败的，last_error 就一直非空，叹号就一直挂。

它为什么"赖着不走"

把这 7 条拉出来看，最新一次运行全是失败，失败类型基本是高峰期的 rate-limited 和 request-refused。

问题就在这：失败的任务，往往正是因为持续被限流、被拒接，才很难自己跑成功。于是陷入循环——跑不成功，叹号不消失；叹号不消失，你以为它坏了；其实它只是上次没跑成。

目前怎么处理

两个路子：

1. 让它成功跑一次。 手动触发，或者避开模型调用高峰等下一个调度点。跑成了，last_error 自动清空，叹号就没了。我那几条大多是高峰期被限流，错峰跑一次基本都消了。
2. 反馈官方。 产品该提供一个"已读 / 忽略"的持久化入口，不该让用户只能靠一次成功运行来消除错误标记。这个现象我已经提交给官方了。

小结

这不算崩溃级 bug，是产品缺了一个"错误已确认"的状态。知道它读 last_error、且只有成功运行才能清，你就不用被红叹号吓到，也能更准确地判断任务到底健不健康。

（你也在用 WorkBuddy 的定时任务吗？遇到过类似的体验，评论区聊聊。）