Repository navigation
plugin-email: sys_email 的 queued 行崩溃后永久滞留 —— 无任何轮询者,且 drain 钩子把失败 warn 掉 #5161
Description
Activity
认领:PM 循环第 6 轮
会话:session_017MCKJaEomEqg4tvz4SzdNd
分支:claude/issue-5161-sys-email-queued-sweep
Worktree:objectstack-issue-5161
域:domain:services
文件面:packages/plugins/plugin-email/src/email-plugin.ts、packages/plugins/plugin-email/src/email-service.ts(如需)、同包测试(越界即停,报告说明)Blocked-by 已解除:#5160 的 PR #5173 已合入(
9c4f1743c),落地判据核过完好。与 #5179 并批(service-queue 包,文件面不相交)。注意 #5177 排在本单之后、会碰同包的 email-service.ts —— 本单不要顺手动 headers/attachments 相关的任何东西。
Generated by Claude Code
复核结论:ACCEPT —— PR #5191,转 ready 并入合并队列。最终 head
13464b40(门禁修复)上 23 个 check run 全部 success/skipped。实现复核(对 diff 独立核过)
- 捞取判据选「年龄 > 5 分钟」而非「早于本次 boot」,理由成立:多实例下 boot 时间没有跨实例含义(兄弟实例一秒前插入的行比我的 boot 还新),年龄是唯一处处同义的属性;之下叠
managedRowIds与sent/message_id两道兜底,与订阅者幂等守卫同套语义。5 分钟的选值有依据(内联重试退避上限 2s,活着的投递早已定稿)。 - 没有第二个载荷生产者:清扫入队走新增的
enqueuePersistedRow,内部就是send()自己的publishRow—— 同一常量、同一 publish options、同一幂等键。还挂着 pending 作业的行被清扫时收敛到那个作业,而不是推第二个 worker 上去;端到端用例证实「已有 pending 作业时清扫不再产生第二个作业」。 - 边界诚实:每 boot 500 行封顶且多读一行判断截断(「还有更多」是事实不是推断);boot 不 await 清扫(滞留邮件不该把服务器挡在端口外);清扫自 catch 打 error,不依赖
kernel:ready传播语义(LiteKernel 吞异常,core: kernel:ready 钩子抛错在 ObjectKernel 上失败 boot、在 LiteKernel 上被吞成一条 error 日志 —— 同一钩子两套失败语义 #5170 在跟);内联模式无跨进程协调直说了——那是 drain 钩子从来就有的边界。 - drain 失败升 error 并带后果与修复;
deliverPersistedRow进了DURABILITY_CRITICAL_CALLEES,以后有人把它的失败降级会被门禁挡住。 - 未加周期性清扫的取舍成立:队列模式新行已由 plugin-email: 邮件投递接入持久化队列 —— send 走 email.send.async / sys_job_queue(重试+DLQ),可配置开关 #5160 覆盖,不为覆盖率造第二套调度;文件面未碰 plugin-email/platform-objects: sys_email 加 headers_json + 有界 attachments_json —— 小附件与自定义 header 取得队列投递资格(#5172 一期) #5177 地盘(headers/attachments 零命中)。
门禁往返一次(今日第三例,
assertEngineDeleteDispatch,已记 #5197),修复与b169f217同形。至此 #5160 的两个直接后续全部落地在途:本单(sys_email 侧)与 #5179(sys_job_queue 侧,PR #5192 已入队)。
Generated by Claude Code
- 捞取判据选「年龄 > 5 分钟」而非「早于本次 boot」,理由成立:多实例下 boot 时间没有跨实例含义(兄弟实例一秒前插入的行比我的 boot 还新),年龄是唯一处处同义的属性;之下叠
- added 3 commits that reference this issue
on Aug 4, 2026
Blocked-by: #5160(同文件
email-plugin.ts,严格串行;且 #5160 落地后本单的正确修法才定形 —— 清扫出的行在队列模式下应交给队列,而不是自己直接投)PM 在回答维护者「邮件有没有队列」时读码发现,维护者已确认要修。
现状
sys_email的status: 'queued'行只有一个消费时机:insert 当时的afterInsertdrain 钩子(email-plugin.ts~390,setTimeout(0)异步自投)。全仓 grep 过:没有任何定时任务、启动清扫或 worker 会再看一眼queued行。两个后果:
queued。一个叫 queued 的状态没有队列在消费它 —— declared ≠ delivered 的又一实例,只是这次声明的是状态词。logger.warn就吞掉(outbox drain failed for …/outbox drain hook error)。按 AGENTS.md degradation-log-level 标准,这是「投递没有发生」级别的失败,应为 error 且带后果与修复;warn 会被启动日志淹没。建议
kernel:ready时做一次启动清扫:捞status='queued'且非本进程 managed 的行 → 队列模式下publish给email.send.async(plugin-email: 邮件投递接入持久化队列 —— send 走 email.send.async / sys_job_queue(重试+DLQ),可配置开关 #5160 的通道),内联模式下deliverPersistedRow;清扫结果(捞了几行、成败各几)打 info 一行。验收