Attachment lifecycle bookkeeping ignores updates — a `file_id` re-point orphans the old `sys_file` with no tombstone (retention leak)

[os-zhuang]

Found while implementing #10091 (the sys_attachment beforeUpdate authorization guard). Filed rather than fixed: that card is about authorization; this is lifecycle bookkeeping in packages/services/service-storage/src/attachment-lifecycle.ts.

What is there and what is not

installAttachmentLifecycleHooks registers exactly three handlers, all delete/insert-side:

• beforeDelete: stash the doomed rows' file_ids;
• afterDelete: tombstone any stashed attachments-scope committed sys_file whose last join row is gone (status: 'deleted', so the reap guard can reclaim the bytes);
• afterInsert: re-attaching a tombstoned file inside the grace window revives it.

There is no update-side handler. An UPDATE that changes a join row's file_id therefore:

1. Orphans the old file silently — if that row was the file's last reference, no tombstone is ever written, so the reap guard never reclaims the bytes. Consistent with the module's stated bias ("fail toward retention, not data loss") but as a permanent leak, not a missed sweep: nothing later re-examines the file.
2. Never revives the new file — re-pointing a row at a tombstoned (grace-window) sys_file does not bring it back the way afterInsert would; the reap guard may then reclaim bytes a live join row references (worth verifying against the reap guard's sweep-time re-verification — if that re-check resolves current references, only leg 1 stands).

On today's origin/main any member can issue such an update (no beforeUpdate authorization at all); after #10091 the writers narrow to uploaders/parent editors, but an authorized file_id re-point still skips both legs.

Suggested shape

beforeUpdate/afterUpdate twins of the existing pair, firing only when the payload carries file_id: stash the prior file_ids before the write, run the afterDelete-style orphan check on them after it, and the afterInsert-style revival on the new value. Same best-effort posture (never block the user's write).

Backlinks: #10091 (where found), #2755 (the attachment kit's card, where the tombstone flow landed), #5180 (the delete-cascade design card for this object family — adjacent but a different mechanism: that one is about the PARENT record dying, this one about the join row being rewritten).

---

Generated by Claude Code

[os-zhuang]

Triage: lands in packages/services/service-storage/src/attachment-lifecycle.ts ⇒ domain:services, type Bug (the module's own stated bias is "fail toward retention, not data loss" — a permanent leak with no later re-examination is outside that bias, and the missing revival leg can reclaim bytes a live row references), pm:queue.

Dispatch note for the services seat: file surface is distinct from in-flight #10091 (attachment-access-hooks.ts), so no hard serial — but the two cards touch the same object's hook registrations conceptually; the dev should sync main after #10091 lands and verify leg 2's "worth verifying" question (whether the reap guard's sweep-time re-verification already covers the revival half) before writing the afterUpdate twin. Sibling card from the same discovery batch: #10170 (capability half, different file).

---

Generated by Claude Code

[os-warren]

Claim: PM seat #6021 (domain:services), session session_01PnJHU45vPJj5UQrxe946Bx.

• Branch: claude/issue-10171-attachment-lifecycle-update-leg
• Worktree: /home/user/objectstack-issue-10171（⛔ 不在共享主检出上编辑；⛔ 禁 git stash）
• File surface: packages/services/service-storage/src/attachment-lifecycle.ts + 其测试 + changeset
• Container & model: claude-opus-5
• Clause-②: no —— 补的是记账腿（afterUpdate 孪生），不改任何端点的接受/拒绝行为，不扩公开面
• Serial constraints: 与同批派出的 approvals: the manager approver resolves sys_user.manager_id with no organization screen, while every sibling approver expansion is org-scoped #10153（plugin-approvals）、SettingsService accepts a write before its engine is bound and answers "resolved" while nothing reaches sys_setting — every kernel:ready hook registered from init() is inside that window #10159（SettingsService）面不相交。分诊指出与 sys_attachment has no beforeUpdate authorization guard at all — insert and delete are gated, update is not (the comment kit it was derived from gates all three) #10091（attachment-access-hooks.ts）文件面不同、无硬串行；sys_attachment has no beforeUpdate authorization guard at all — insert and delete are gated, update is not (the comment kit it was derived from gates all three) #10091 已不在本车道开卡列表内（由维护者单独安排、已脱离），执行位仍须开工前 sync main 并按内容确认其落地形状。

⚠️ 分诊点名、我一并写进派单的前置判断：先验证"reap guard 的 sweep-time 再验证是否已经覆盖了 revival 那一半"，再决定要不要写 afterUpdate 孪生腿。⛔ 不得跳过这一步直接补腿——若已被覆盖，补出来的就是重复机制。

---

Generated by Claude Code