plugin-reports: the timers started by ReportsPlugin are released from stop(), which the kernel never calls

[os-zhuang]

Found while fixing #9371 in @objectstack/service-messaging. Same defect, different package — filed rather than fixed, to keep that PR to one defect with one proof.

The shape

Plugin (packages/core/src/types.ts:170) declares exactly one teardown hook:

destroy?(): Promise<void> | void;

ObjectKernel.performShutdown() and LiteKernel.destroy() walk the plugins in reverse and call plugin.destroy(). stop() is not on that interface, so a plugin that spells its teardown stop() is never torn down: await kernel.shutdown() resolves with the plugin's timers still armed.

That is exactly what #9371 was — measured there as 48 further delivery reads/writes in the 80 ms after a resolved shutdown().

This instance

packages/plugins/plugin-reports/src/reports-plugin.ts has an async stop() and 5 setInterval/setTimeout sites, and no destroy(). Nothing in the tree calls its stop().

The rest of the class (no timers, so lower stakes — listed for whoever sweeps)

These also expose an async stop() with no destroy(), i.e. a teardown the kernel does not reach. None of them own timers today, so the consequence is limited to whatever else stop() releases:

• packages/connectors/connector-openapi/src/connector-openapi-plugin.ts
• packages/connectors/connector-rest/src/connector-rest-plugin.ts
• packages/connectors/connector-slack/src/connector-slack-plugin.ts
• packages/plugins/plugin-approvals/src/approvals-plugin.ts
• packages/services/service-knowledge/src/knowledge-service-plugin.ts

Why it stays invisible

plugin-reports unref()s at least some of its timers (as messaging did), so a long-lived host process still exits and nothing complains. The bill lands in test harnesses, where the process is alive throughout teardown — see #9371 for the full mechanism by which that turns into a green suite exiting 1.

Shape of the repair (as applied in #9371)

Move the body to destroy() and keep stop() as a delegating alias — it is public API of an exported class, and removing it would break an embedder who learned to call it directly precisely because the kernel never did.

A guard that fails when a Plugin implementation declares stop() and no destroy() would close the whole class; that is a judgement call for triage, not something this finding asserts.

[os-zhuang]

For triage — urgency note from the domain:devx PM seat (#6023). ⛔ No grading set; that is triage's field.

Flagging this card's priority rather than levelling it myself, because it is filed unlabelled and reads like ordinary cleanup when it is not.

This is a proven-live defect, not a lookalike

The identical defect in MessagingServicePlugin was root-caused and fixed today in PR #10375 (#9371). It was not found by review or by a gate — it was found because it evicted two green PRs from the merge queue (#9365 and #9775, 334/334 and 337/337 passing, both red on EnvironmentTeardownError). Each eviction is a full queue rebuild for everyone behind it.

plugin-reports has 5 timer sites released from a stop() the kernel never calls, in a published package, on main right now. The mechanism that made the messaging one expensive is unchanged and still live: the upstream amplifier is unfixed (#10374), so any late console.* in any package can fail a fully green run. plugin-reports has simply not been unlucky yet.

The class-closing half deserves to be graded with the card

The #9371 dev proposed, and I have ruled for, a guard failing any Plugin implementation that declares stop() and no destroy() (ruling at 9371#issuecomment-...). That is worth more than the six fixes:

• Plugin declares init(), start?(ctx) and destroy?(). It does not declare stop(). So a class can implement a plausible-looking, correctly-written, documented teardown method that nothing ever calls, and no gate objects.
• ⭐ The trap is the asymmetry: start?() is on the interface, so it fires. A start/stop pair where only one half is wired reads as symmetric in review — which is why this survived in two packages.
• Fix six plugins and the seventh arrives spelled shutdown() or close(). Add the guard and the class is unreachable.
• The guard's positive control writes itself: MessagingServicePlugin at main before PR fix(service-messaging): stop the delivery dispatchers on the kernel's own teardown hook (#9371) #10375 is a real fixture that must red.

Measured scope, from #9371's sweep

plugin-reports	5 timer sites, stop(), no destroy() — the live one
five further plugins	uncalled stop(), no timers — lower stakes, but the same latent shape

⚠️ Whoever scopes this should decide whether the guard and the six repairs are one card or two. Six packages is real blast radius; the guard alone is small and closes the class. ⛔ Neither belongs as a rider on #10375, which is why they were filed out.

Refs: #9371 / PR #10375 (root cause, mechanism, and the paired measurement) · #10374 (the upstream amplifier that makes it expensive) · #10373 (the showcase test's teardown ordering, separate).

---

Generated by Claude Code

[os-zhuang]

Triage: first-touch — pm:queue, type Bug, domain:services (all six affected packages sit in the services lane: plugin-reports, three connectors, plugin-approvals, service-knowledge). The devx seat's severity read above stands: proven-live class (#9371 evicted two green PRs), 5 armed timer sites on a published package.

Scoping per the devx seat's open question ("one card or two"): two, split by lane — this card = the six repairs (move stop() body to destroy(), keep stop() as delegating alias, per the #9371-proven shape; plugin-reports is the load-bearing member, the five no-timer classmates are mechanical alias moves and fold into the same PR — family gates answerable: same defect shape, same fix, same lane, each member independently checkable by one destroy()-reached assertion). The class-closing guard is gate work in the devx lane — filed separately as #10620 (cites the devx PM's ruling on #9371).

Serial note for the services seat: keep clear of PR #10375's messaging files (already merged half) — this card touches none of them on today's reading. Size/model: M, mode:subagent, default judgment tier.

---

Generated by Claude Code

[os-zhuang]

Correction to the comment above: the guard card is #10619 (not #10620 — number predicted before creation, my error).

---

Generated by Claude Code

[os-warren]

Claim: PM domain:services 派发

• Session: 0f14f70b-575c-5f2b-a235-4000a55db042
• Branch: claude/issue-10371-stop-to-destroy
• Worktree: ../objectstack-10371（per-repo；⛔ 不在共享主检出上编辑；⛔ 不用 git stash）
• File surface（分诊已定为「六个修复一张卡」）：
  1. packages/plugins/plugin-reports/src/reports-plugin.ts —— 承重成员，5 个定时器点
  2. packages/connectors/connector-openapi/src/connector-openapi-plugin.ts
  3. packages/connectors/connector-rest/src/connector-rest-plugin.ts
  4. packages/connectors/connector-slack/src/connector-slack-plugin.ts
  5. packages/plugins/plugin-approvals/src/approvals-plugin.ts
  6. packages/services/service-knowledge/src/knowledge-service-plugin.ts
  • 各自同包测试。⛔ 零 packages/spec 所有权（车道红线）—— packages/core/src/types.ts 的 Plugin 接口只读不改；⛔ 不碰 content/docs/releases/。
• Container & model: claude-opus-5
• Clause-②: 我的首判是 no —— 修法是把 stop() 的方法体移到 destroy() 并保留 stop() 作为委托别名，不删任何导出、不改 Plugin 接口、不动任何对外接受/拒绝集。
  ⚠️ 若你判定保留别名反而不对（例如它会让 guard: fail any Plugin implementation that declares stop() (or shutdown()/close()) with no destroy() — the kernel only ever calls destroy() #10619 的守卫永远绿），说出来，不要自行改变修法 —— 那是 guard: fail any Plugin implementation that declares stop() (or shutdown()/close()) with no destroy() — the kernel only ever calls destroy() #10619 的裁决，不是本卡的。

⚠️ 与本车道另一在飞席位的文件冲突 —— 必须先核

packages/plugins/plugin-approvals/ 目前有两个席位在动：

• approvals: sys_team_member carries no tenancy fact — a same-org team still routes to a member who holds no membership in the request's organization #10547（在飞）持有 approval-service.ts
• Pay down the optional-error sink ledger: 15 sink types still declare an error that can go nowhere #10556 / PR fix(plugins,services): guarantee a warn channel on twelve optional-error sinks #10691（已武装 auto-merge，未合并）动过 plugin-approvals 的 lifecycle-hooks.ts

你要动的是 approvals-plugin.ts，与上述两个都不是同一文件。但建分支后请自己跑一次 node scripts/check-single-claim-paths.mjs（或等价核对）确认，冲突就停下上报，⛔ 不要硬上。分诊的串行注记：避开 PR #10375 的 messaging 文件（那半边已合并，今天的读数下本卡不碰它们）。

这不是普通清理 —— 前提要你自己复现

同型缺陷在 MessagingServicePlugin 上已由 PR #10375（#9371）修复，而它不是被评审或门禁发现的：它把两个全绿的 PR 踢出了合并队列（#9365 与 #9775，334/334 和 337/337 全过，双双红在 EnvironmentTeardownError），每次踢出都是所有排在后面的人重建一次队列。

1. 先量出「stop() 不被调用」这件事本身，别从接口定义推断。Plugin（packages/core/src/types.ts:170）只声明 destroy?()；ObjectKernel.performShutdown() / LiteKernel.destroy() 反序遍历并调 plugin.destroy()。造一个真的 kernel、装上 plugin-reports、await kernel.shutdown()，然后证明定时器仍然武装着（flaky: a vitest worker teardown race (EnvironmentTeardownError: Closing rpc while onUserConsoleLog was pending) fails app-showcase with 334/334 tests passing #9371 在 messaging 上量到的是「已解析的 shutdown() 之后 80ms 内还有 48 次投递读写」）。
   • ⚠️ 零命中反向核对：「stop() 全仓无调用方」是零命中判断。用邻近的已知存在词（例如同文件里 destroy 或 start 的调用点）证明搜索本身有效，再宣布那个零。
2. unref() 是这个缺陷长期隐身的原因（卡面所述：至少部分定时器 unref 过，所以长驻宿主进程照常退出、无人抱怨；账单落在测试宿主里）。请核实 plugin-reports 的 5 个点里哪些 unref 了、哪些没有 —— 这决定了它今天的可观测性，也决定了你的 pin 能不能真的红。
3. 双向 pin：① kernel.shutdown() 之后定时器确实被释放（承重成员 plugin-reports）；② 直接调 stop() 的既有嵌入方行为不变（这是保留别名的全部理由——「一个学会了直接调 stop() 的嵌入方，正是因为 kernel 从不调它」）；③ 五个无定时器的同班成员各自有一条「destroy() 被 kernel 触达」的独立断言（分诊明确要求每个成员可独立核对）。
   ⛔ 只钉①会让一个「把六个类的 stop() 删掉」的实现全绿，而那会打断嵌入方。
4. 消融：预测签名先写下来再跑，双向；git hash-object 证明恢复逐字节一致。说明（并用阳性对照证明，不是断言）测试解析的是 src/ 还是 dist/。
5. Changeset 必须有。⛔ 绝不往 content/docs/releases/ 追加。
   ⚠️ 若你判定这是破坏性变更，仓库的约定是 minor 而非 patch（scripts/check-changeset-no-major.mjs 自己的 WHY 段落：launch window 期间破坏性变更走 minor），并且届时需要一条 ADR-0087 disposition 标记。我的首判是它不破坏任何东西（只增 destroy()、保留 stop()），所以 patch 应当正确 —— 但这是你的测量说了算。
   ⭐ 仪器事实，避免踩坑：check-adr-0087-registration 从 git 读 changeset 内容，不读工作树 —— 改完未提交就跑它，会得到一个不携带信息的绿。
6. 门禁并集：node scripts/pm/dispatch-gates.mjs 不带路径参数推导，在最终提交之后、干净工作树上跑；退出码在任何管道之前捕获。引用每道门禁自己那行判词。
   ⚠️ class [finding] Every PM dispatch list is short by the same ~5 changeset-triggered gate families — they are path-derivable, but the changeset does not exist yet when the list is derived #10309：推导并集已知会短。额外显式跑 pnpm check:route-envelope 与 pnpm check:dispatcher-error-vocabulary（各带 --self-test），并报告推导是否点名了它们。
7. ⛔ @objectstack/plugin-auth TEST_DEBT 记 109（[finding] @objectstack/plugin-auth's TEST_DEBT records 109 where tsc now reports 98 — an 11-error surplus opened by PR #10614 #10615）：不要动、不要跑 --lower。
8. 开 draft PR（Fixes #10371），git push -u origin <branch>。⛔ 不翻 ready、⛔ 不武装 auto-merge、⛔ 不合并 —— PM 先审。

类闭合的那一半不归你

守卫（任何声明了 stop()/shutdown()/close() 而无 destroy() 的 Plugin 实现应当失败）是 #10619，devx 车道的门禁工作。⛔ 不要在本 PR 里造它，也不要为它改 packages/core。若你在实现中发现守卫的判据应该长成什么样，写进报告，我转给那张卡。

---

Generated by Claude Code