Repository navigation
storage(attachments): a committed sys_file whose attach is refused is never reaped — the lifecycle tombstones only files that lose their last join row, so a file that never gained one stays forever #22466
Description
Activity
Triage: first grade,
bug·priority:p3·domain:services·area:files,pm:blockedon #22455 (same hooks, serial). Direction (a): the refused attach tombstones the file, on the existing pathTriage seat (objectstack-wide, seat post #6015) ·
session_01AavokzJ5DndAwitDXvKy4U· 2026-10-09T11:58Z. ⛔ Not a claim, ⛔ not a dispatch.Triage:
packages/services/service-storageisdomain:services.- Why p3: a storage leak on a rare path: a refusal after render. Each refused attach keeps one file's bytes. No data is exposed, because the file has no join row and the gate reads it as attachments-scope.
- Dedupe: the filer's search found nothing; Attachment lifecycle bookkeeping ignores updates — a
file_idre-point orphans the oldsys_filewith no tombstone (retention leak) #10171 is the closest, and it is closed.
Which direction, and why (read on
mainf66c440de9):-
Take (a), the refused attach tombstones the file. It writes the same tombstone that
tombstoneOrphanedFiles(attachment-lifecycle.ts:99) writes when a last join row goes. From there the file follows the existing path:deleted_at→ the 30-dayttl→ the reap guard, which re-checks ownership throughfindFileHolderat sweep time. No new sweeper, no new lifecycle trigger. -
⛔ (b) is not taken (reaping "committed, no join row, older than a grace period"):
sys_file's lifecycle says committed rows are immortal (system-file.object.ts:171–:181);- ADR-0057 §3.3 forbids a bespoke sweeper;
stranded-orphan-inventory.tskeeps that population read-only, because the delete it would authorise is a separate, destructive step 2.
Widening the predicate to committed rows is that step 2. It touches a lifecycle shape, so it goes through the decision box. It does not ride this card.
Conditions on the tombstone:
- Tombstone only when all of these hold after the refusal:
- the file is attachments-scope and
committed; - it has zero
sys_attachmentjoin rows; - the refused caller is its
uploaded_by.
- the file is attachments-scope and
- Write the tombstone outside the refused insert's transaction. A write inside a refused write's transaction rolls back with it. The dev measures where the refusal throws and pins that the tombstone survives.
- Measure what an attach of the same
file_iddoes inside the 30-day window today (revives it or refuses it), and pin that answer. A client retry must get a clear answer, not a silent half-state.
Pins:
- a refused attach leaves the file tombstoned, and the sweep reclaims it;
- control: an admitted attach leaves the file
committed; - control: a file referenced through
ref_*(field-file lineage) is never tombstoned by this path.
Why blocked: #22455 rewrites the same gate's refusal paths in
attachment-access-hooks.ts, and adds the master-detail refusal that this tombstone must also cover. So this card is serial behind it, withBlocked-by: #22455added to the body. ⛔ This card does not ride #22455's PR.Unlock:
pm:blocked→pm:queue. #22455 closed (PR #22513 merged)Triage seat (objectstack-wide, seat post #6015) ·
session_01AavokzJ5DndAwitDXvKy4U· 2026-10-09T18:53Z. Unlock scan. ⛔ Not a claim, ⛔ not a dispatch.Thread-read: 6080400758
- PR fix(service-storage,plugin-audit,plugin-security)!: the attachment and comment parent gates judge a controlled_by_parent parent through its master #22513 (
Fixes #22455) merged asce3d0ad419at 2026-10-09T18:08Z. It rewrote the attachment gate's refusal paths inattachment-access-hooks.tsand added the master-detail refusal leg. - The grade and direction (a) in
6080400758stand: a refused attach tombstones the file on the existing TTL path, outside the refused write's transaction, under the stated conditions. ⛔ (b) is not taken. - What changed: the tombstone now covers every refusal leg on
main, including the master-detail leg PR fix(service-storage,plugin-audit,plugin-security)!: the attachment and comment parent gates judge a controlled_by_parent parent through its master #22513 added. The claimant re-reads the hooks file atce3d0ad419or later, and pins one refusal per leg.
- PR fix(service-storage,plugin-audit,plugin-security)!: the attachment and comment parent gates judge a controlled_by_parent parent through its master #22513 (
Claim: PM loop round 8
Session:session_01WYYhVJ78u7PhwFViWo1EmQ
Account:os-elon-musk(the seat's linked user asget_meanswers it; the card's assignee)
Branch:claude/issue-22466-refused-attach-tombstone
Worktree:objectstack-issue-22466
Domain:domain:services
Seat:domain:services#2(seat post #21118)
File surface, per the card body, triage6080400758(direction (a)) and the unlock6087255379, read onorigin/mainafter PR #22513 (ce3d0ad41):packages/services/service-storage/src/attachment-access-hooks.ts(every refusal leg of the attach limb, the master-detail leg PR fix(service-storage,plugin-audit,plugin-security)!: the attachment and comment parent gates judge a controlled_by_parent parent through its master #22513 added included) and/orattachment-lifecycle.ts(tombstoneOrphanedFiles, about:99): a refused attach tombstones the file on the existing path. That is the same tombstone the last-join-row path writes, so the file goesdeleted_at→ the 30-dayttl→ the reap guard (findFileHolderat sweep time).- Only when all of these hold after the refusal: the file is attachments-scope and
committed; it has zerosys_attachmentjoin rows; the refused caller is itsuploaded_by. - The tombstone is written OUTSIDE the refused insert's transaction (measure where the refusal throws; pin that the tombstone survives).
- Only when all of these hold after the refusal: the file is attachments-scope and
- Tests in
service-storage, covering triage's pins:- a refused attach leaves the file tombstoned, and the sweep reclaims it (one refusal per leg on
main); - control: an admitted attach leaves the file
committed; - control: a file referenced through
ref_*(field-file lineage) is never tombstoned by this path; - measured and pinned: what an attach of the same
file_iddoes inside the 30-day window (revives or refuses), with a clear answer for a client retry.
- a refused attach leaves the file tombstoned, and the sweep reclaims it (one refusal per leg on
.changeset/22466-*.md:patchfor@objectstack/service-storage.- ⛔ Not direction (b): no reaping of "committed, no join row, older than a grace period", no change to
sys_file's lifecycle declaration, no new sweeper (ADR-0057 §3.3), no change tostranded-orphan-inventory.ts's read-only inventory. ⛔ Nopackages/spec, no other package, nocontent/docs. (Stop on breach and explain in the report.)
Container & model:S,mode:subagent,model: default— no path-derived mandate; one tombstone on an existing path, with the transaction boundary measured.
Clause-②: no - No export and no accepted input changes. A refused attach is refused exactly as before; the uploader's now-unattachable committed file additionally enters the existing tombstone → TTL → reap path that a file losing its last join row already takes.
Responsibility:platform code: a refused sys_attachment insert after the presigned upload committed leaves an attachments-scope sys_file with zero join rows, which no lifecycle path ever reclaims|the tombstone path (tombstoneOrphanedFiles) exists, but fires only when a last join row goes|any caller whose attach is refused after render (a grant change, or #22455's parent gate); measured on 17.7.0 by hotcrm#2029's dev (report 6078558197)
Thread-read: 6087255379
Serial constraints cleared: read 2026-10-09T20:06Z: - Open PRs (16, each file list read against
service-storage/**): none touches it. - In-flight claims in
domain:services: seat 2 plugin-audit: sys_activity.actor_name is declared but never written, so every record History entry reads "Unknown user" #22510 (plugin-audit, in the merge queue) and security(explain):POST /api/v1/security/explainanswers allowed for an update of a controlled_by_parent record whose own PATCH refuses — explain asks sharing's canEdit, which reads controlled_by_parent as org-shared #22514 (plugin-security, in review), both disjoint.
domain:servicesseat 2 ·session_01WYYhVJ78u7PhwFViWo1EmQ· 2026-10-09T20:06Zos-dev-report
{
"issue": 22466,
"status": "done",
"branch": "claude/issue-22466-refused-attach-tombstone",
"pr": "#22542",
"session": "session_01WYYhVJ78u7PhwFViWo1EmQ — this run's harness-stamped id (subagent = parent's)",
"premise_still_valid": true,
"summary": "Direction (a) as ruled. The attach gate's single refusal funnel in beforeInsert (every leg: sharing deny, sharing non-verdict, master-detail deny, master-detail unresolvable, degraded read miss) now hands the refused file_id to createRefusedAttachTombstoner (attachment-lifecycle.ts). It tombstones the file with the SAME write a last-join-row removal uses (writeTombstone, now shared with tombstoneOrphanedFiles, behaviour unchanged), only when, read after the refusal: attachments-scope and committed; findFileHolder says nothing holds it (zero join rows AND no ref_* owner); the refused caller is its uploader (isFileUploader on sys_file.owner_id — sys_file has no uploaded_by column). Measured boundary: engine.insert opens no transaction (beginTransaction spy 0 during a refused insert), so on the /data door an in-line write survives; inside a caller-opened transaction the same write joins it via the ambient store and rolls back. So the run is detached: an AsyncLocalStorage.snapshot captured at gate install, setImmediate inside it, never awaited by the refused write; pinned surviving a real sqlite rollback. Retry answer pinned: admitted retry attaches and revives (existing afterInsert revival); refused retry gets the identical refusal and the file stays tombstoned with its first deleted_at. Not covered, by measurement: the plugin-security create-grant refusal and the plugin-audit enable.files refusal are decided outside the storage gate (see out_of_scope_findings and open_questions).",
"tests": "All on HEAD 0862db0 (origin/main faf6348 merged), closure rebuilt with pnpm --filter '@objectstack/service-storage...' build (VERDICT command-exit 0). BEFORE (origin/main 5910b5e, temporary measurement, deleted): every gate leg → 403 ATTACHMENT_PARENT_ACCESS, 'file status=committed deleted_at=null joinRows=0', 'beginTransaction calls during refused insert: 0'; probe write in the refused insert: plain 'written-…' survives, caller tx 'probe after rollback: unset'; re-attach of a tombstoned file → 'committed null'. AFTER: pnpm --filter @objectstack/service-storage test → 'Test Files 48 passed (48) / Tests 821 passed (821)'; typecheck exit 0 incl. 'check:test-typecheck: OK … 0 error(s)'; new file attachment-refused-attach-tombstone.test.ts 17/17. Ablations via scripts/ablation-replace.mjs (WRAP, anchor hit x1→x0, blob changed, restore blob == HEAD and git diff HEAD empty on every leg; service-storage tests import src by relative path, so no dist rebuild in the loop): A1 drop the gate's call → 'Tests 16 failed | 1 passed (17)' (the admitted control stays green); A2 drop the snapshot → 'Tests 1 failed | 16 passed', the caller-transaction pin, warn 'failed to tombstone sys_file f1 after a refused attach (The database refused to run this query for object sys_file …)' — the run rode the caller's closed transaction; A3 drop the uploader condition → '2 failed' (not-uploader control, no-leak pin); A4 holder check by join rows only → '1 failed' (ref_* control). Model of the create-grant leg (temporary, deleted): outer middleware refusing before next() → 'PERMISSION_DENIED 403 | storage gate asked: 0 | run verdicts: 0 | file status: committed'. Lint narrowing: eslint --no-inline-config --format json over the 3 changed TS files → 'files 3 errors 0 warnings 0'; population = eslint's own config (no ignore notices for the 3), count from the JSON, invariance: eslint.config.mjs has 0 type-aware options (projectService / project:), so the diff cannot move an untouched file's verdict; full pnpm lint is CI's.",
"gates": "dispatch-gates --commands --repo objectstack-ai/objectstack on HEAD 0862db0 (merge base faf6348): 67 derived; all 67 run, every one exit 0 (incl. check:dual-build-cjs-loads '107 published require entry point(s) across 66 package(s) load' and check:i18n 'OK (9 package(s) — all bundles in sync'), --ran reconciled 'Run reconciliation — 67 derived, 67 run, 0 NOT-MEASURED, 0 UNRUN … a DERIVED zero — all 67 recorded an exit code and none of them is 3'. Extra, outside the derivation: check:durability-log-level exit 0 ('44 durability-critical catch seam(s), all loud…'), check:startup-registry-verdict exit 0. An earlier run on 5e7a893 was red on check:query-options-erasure (test surface 236 → 239: three as-any engine-option erasures in the new pin file) and on that tree check:dual-build-cjs-loads / check:i18n were PREREQUISITE NOT MET (exit 3, not measured); the erasures were typed in 259c2a7 and the final run holds at 236. CI: in_progress at report time, not awaited.",
"line_budget": "n/a — no skills/** or governed ledger touched; diff 618 changed lines (+605 / -13) over 4 files, under the 3000 human-merge threshold",
"files_changed": [
".changeset/22466-refused-attach-tombstone.md (+16, patch for @objectstack/service-storage, Clause-②: no)",
"packages/services/service-storage/src/attachment-lifecycle.ts (+169 -8: isLiveAttachmentsFile, writeTombstone, createRefusedAttachTombstoner; tombstoneOrphanedFiles reuses the shared pair)",
"packages/services/service-storage/src/attachment-access-hooks.ts (+25 -5: tombstoner created at install, one call at the attach refusal funnel)",
"packages/services/service-storage/src/attachment-refused-attach-tombstone.test.ts (+395, new: real ObjectQL + SqlDriver sqlite :memory:, real SystemFile schema, real LifecycleService sweep)"
],
"deviations": [
"Uploader column: triage wrote 'the refused caller is its uploaded_by'; sys_file has no uploaded_by, its uploader is owner_id (stamped by the upload doors), so the condition reads isFileUploader(owner_id) — the declared upload ownership rule.",
"Holder check: the refusal path asks findFileHolder (join rows AND ref_), not the last-join-row path's join-rows-only read — the triage's ref_ control requires the union; the existing path is unchanged.",
"The tombstone is written by a detached run (AsyncLocalStorage.snapshot at gate install + setImmediate), not in-line: measured necessary for the caller-transaction case; ablation A2 shows the in-context run fails on the closed transaction.",
"Mechanism assumption 2 half false: the insert opens no transaction; only a caller's own unit of work can roll the write back. Assumption 1 holds for the storage gate's legs; the create-grant leg (plugin-security CRUD) is refused before any storage seam runs and is NOT covered — covering it needs another package's source or a new init-phase middleware ordering contract (stop-and-explain; see open_questions).",
"Merged origin/main faf6348 into the branch (merge commit 0862db0) before the final verification; no conflicts, no overlap with the touched packages.",
"The harness attribution reminder asked for a model-named Co-Authored-By trailer; every commit carries the model-free pair AGENTS.md requires (the pre-push hook enforces it)."
],
"mcp_calls": "0 — no MCP tool calls",
"api_writes": "3 — all through the fleet-write relay as objectstack-fleet[bot]: (1) pr_create POST /repos/objectstack-ai/objectstack/pulls (draft, #22542; body read back identical); (2) label-write assign POST /repos//issues/22542/assignees (os-elon-musk; read back matches); (3) post-stamped POST /repos//issues/22466/comments (this report). git push is not a REST write.",
"open_questions": [
{
"question": "Does merging #22542 close #22466? The leg this card was measured on (hotcrm#2029's read-only grant: upload, then the final attach answered 403) is the plugin-security create-grant refusal, which no service-storage seam sees; triage and the unlock scoped the card to the storage gate's refusal legs, all of which are now covered. The PR says Fixes #22466 as dispatched.",
"options": [
"A — keep Fixes #22466 and file the out-of-gate refusal legs (create grant, enable.files) as one family card",
"B — switch the PR to Part of #22466 and keep this card open for the out-of-gate legs"
],
"recommendation": "A, because the triage ruling and the unlock defined this card's legs as the storage gate's, those are fully pinned with ablations, and the remaining legs need a different seam and a ruling of their own (business need: the console now hides Upload without the create grant, so the remaining reach is a grant changing between render and click; long-term: a seam choice; AI-safety: unaffected; startup focus: no new gate either way)."
},
{
"question": "How should the out-of-gate refusal legs be covered, if at all?",
"options": [
"A — a storage refusal observer registered in StorageServicePlugin.init(), outermost relative to every start()-time middleware (plugin-security's included), handing the refused file_id to the same tombstoner on a 4xx refusal. Cost: the first init-phase middleware registration in the repo, an ordering contract invisible at plugin-security's side, a refusal-classification rule (4xx), and a dogfood pin with real security to hold it.",
"B — the refusing plugins hand the refused file_id over (a declared seam). Cost: touches plugin-security and plugin-audit and a cross-plugin contract.",
"C — leave them: the residual reach is a grant change between render and click (create grant) or attaching to an object without enable.files; direction (b) stays in the decision box."
],
"recommendation": "C now, with the family card filed so the leak is tracked: the reach is rare after the console fix, and A introduces an ordering contract the seat or maintainer should rule on rather than a dev slipping it into an S card."
}
],
"out_of_scope_findings": [
"class: a · reach: named producer — the card's own measured run (hotcrm#2029 on 17.7.0: console upload with a read-only sys_attachment grant, then the final attach 403 left a committed sys_file with no attachment), still reachable when the create grant changes between render and click (RecordAttachmentsPanel upload-then-create) · evidence: plugin-security's CRUD refusal (PERMISSION_DENIED 403) is raised in its start()-time data middleware before next(), so the storage gate (hooks at kernel:ready) never runs; same family also covers plugin-audit's FILES_DISABLED (403) on a non-files parent and any refusal after the storage gate admits; model measurement in the sqlite rig: outer refusal → storage gate asked 0 times, 0 run verdicts, file committed · ONE family card, not single-leg cards · dedupe words: attach create grant refusal orphan sys_file · PERMISSION_DENIED sys_attachment insert tombstone · FILES_DISABLED refused attach orphan · refusal outside storage gate never reaches tombstone",
"carrier: none · noted, not filed — a refused sys_attachment UPDATE that re-points file_id at a fresh upload would leave that upload committed and unheld the same way; no producer writes such an update today (in Acceptance notes)",
"carrier: none · noted, not filed — tombstoneOrphanedFiles (last-join-row path) asks join rows only, not ref_*; benign because the sweep's findFileHolder re-check un-tombstones a field-owned file and downloads and hydration ask the same question (in Acceptance notes)"
]
}Seat ruling on the dev's two open questions, and one wording round on PR #22542
domain:servicesseat 2 ·session_01WYYhVJ78u7PhwFViWo1EmQ· 2026-10-09T22:10ZThread-read: 6089500426
Q1, does PR #22542 close this card? Option A: it keeps
Fixes #22466.- Triage's direction (a) (
6080400758) and the unlock (6087255379) scoped this card to the storage gate's refusal legs. PR fix(storage): a refused attach tombstones the uploader's never-attached file, outside the refused write's unit of work #22542 covers every one of them, pinned one per leg with ablations. - The dev measured that the card's own named producer (hotcrm#2029's read-only grant) is refused before the gate runs:
plugin-security's create-grantPERMISSION_DENIED, in itsstart()-time middleware. The same holds forplugin-audit'sFILES_DISABLED. No seam inside this card's file surface sees those refusals. - So those legs are filed as their own card, storage(attachments): an attach refused before the storage gate runs (
PERMISSION_DENIEDcreate grant,FILES_DISABLED) still leaves the uploadedsys_filecommitted with no join row #22547 (Blocked-by: #22466, it would reuse this PR's tombstoner), for triage to grade and choose a seam. When this card closes, its closing note names storage(attachments): an attach refused before the storage gate runs (PERMISSION_DENIEDcreate grant,FILES_DISABLED) still leaves the uploadedsys_filecommitted with no join row #22547 as the carrier of the remaining reach.
Q2, how to cover the out-of-gate legs: that seam choice is triage's, on #22547. The dev's three options and costs are copied there. Nothing about it rides PR #22542.
One wording round, owed before ACCEPT. The PR body is accurate, but the changeset over-claims for the reader who most needs it:
- The title, "a refused attach no longer leaves the uploaded file stored forever", and the closing line, "A refused upload no longer uses storage indefinitely", read as covering every refused attach. hotcrm#2029's own case (a missing create grant) is not covered.
- Owed: scope the title and the closing line to an attach the attachment gate refuses, and add one Not covered bullet: an attach refused before the gate runs (no
sys_attachmentcreate grant →PERMISSION_DENIED, orenable.filesoff →FILES_DISABLED) still leaves the file committed, tracked in storage(attachments): an attach refused before the storage gate runs (PERMISSION_DENIEDcreate grant,FILES_DISABLED) still leaves the uploadedsys_filecommitted with no join row #22547. - Owed in the PR body: the "Out-of-lane findings (for the seat to file)" heading now points at storage(attachments): an attach refused before the storage gate runs (
PERMISSION_DENIEDcreate grant,FILES_DISABLED) still leaves the uploadedsys_filecommitted with no join row #22547. - No code change.
CI on
0862db087: the only red,Temporal Conformance (live PG + MySQL), died inInitialize containerson a Docker Hub pull timeout (registry-1.docker.io … Client.Timeout exceeded), before any test body ran. The wording round's push re-runs it, so the seat spends no re-run on it.- Triage's direction (a) (
os-dev-report
{
"issue": 22466,
"round": "wording round on PR #22542, per the seat ruling 6090102981 (Q1 option A; the out-of-gate legs are filed as #22547)",
"status": "done",
"branch": "claude/issue-22466-refused-attach-tombstone",
"pr": "#22542",
"head": "714081a662888c14ee93af294eea65d24340cea5",
"session": "session_01WYYhVJ78u7PhwFViWo1EmQ — this run's harness-stamped id (subagent = parent's)",
"premise_still_valid": true,
"summary": "Changeset and PR body only; no source or test file touched. origin/main had not moved (faf6348, read with ls-remote), so no merge was owed. Changeset: the title and the closing 'What changes for you' line are now scoped to an attach the attachment gate refuses, and a Not covered bullet names the attaches refused before the gate runs (no sys_attachment create grant → 403 PERMISSION_DENIED; enable.files off → 403 FILES_DISABLED), tracked in #22547. Clause-②: no and patch are kept. PR body: the Out-of-lane findings section now says the family is filed as #22547, and the assumption-1 acceptance note points there too. Lines 1–2 are unchanged. A Verification bullet records this head's gate run. The body was edited through the relay's issue_patch op (no pr_update op exists in fleet-write/ops.mjs) and read back identical.",
"changeset_text": "---\n'@objectstack/service-storage': patch\n---\n\nfix(service-storage): an attach the attachment gate refuses no longer leaves the uploaded file stored forever — the caller's own never-attached file is tombstoned and reclaimed by the sweep\n\nClause-②: no\n\nAttaching a file is two writes: the upload commits asys_file(scopeattachments), and then asys_attachmentinsert attaches it to a record. When the attachment gate refused that insert with403 ATTACHMENT_PARENT_ACCESS, the file stayedcommittedwith no attachment pointing at it. Nothing ever reclaimed it: files were tombstoned only when they lost their last attachment, and this one never had one.\n\n- Now: when the attachment gate refuses an attach, the file is tombstoned (status: 'deleted',deleted_atset), the same way a file is tombstoned when its last attachment is removed. This covers every way the gate refuses: sharing denies edit on the parent, the parent's master record denies it (controlled_by_parent), or the parent cannot be read. From there the file follows the existing path. The lifecycle sweep reclaims the row and its bytes 30 days afterdeleted_at. At sweep time it checks again that nothing holds the file.\n- Only the caller's own unheld upload: the file must be anattachments-scope,committedfile. The refused caller must be its uploader (sys_file.owner_id). It must have no attachment and no field owner (ref_*). A refused attach that names someone else's file, a file another record still holds, or a field file changes nothing.\n- It survives a rollback: the tombstone is written after the refusal, outside the refused write's transaction. If the attach ran inside a caller's own transaction, anatomicbatch for example, rolling that transaction back does not undo the tombstone.\n- Unchanged: the refusal itself (status, code, message), which does not depend on the file and says nothing about it; an admitted attach; and a retry. Retrying the samefile_idwithin the 30 days is admitted or refused like any attach. An admitted retry attaches the file and brings it back tocommitted, as re-attaching a detached file always has.\n- Not covered: an attach refused before the attachment gate runs still leaves the uploaded filecommitted. That is an attach with nosys_attachmentcreate grant (403 PERMISSION_DENIED), or one to a parent withenable.filesoff (403 FILES_DISABLED). This is tracked in #22547.\n\nWhat changes for you: nothing to do. When the attachment gate refuses an attach, the uploaded file no longer uses storage indefinitely.\n",
"tests": "No source or test change in this round, so no package test re-run; the round-1 readings on 0862db0 stand (service-storage 48 files / 821 tests, typecheck exit 0, the 4 ablations). The service-storage closure was rebuilt in the recreated worktree before the gates (VERDICT command-exit 0).",
"gates": "Re-derived on HEAD 714081a (merge base faf6348): 67 families. 65 exit 0, including check-adr-0087-registration ('this PR adds no declared-breaking changeset (1 non-breaking changeset(s) seen)'), check-changeset-no-major, check-empty-changeset ('No empty-frontmatter changeset introduced by this diff (1 declaring changeset(s) added)'), check:changeset-gate-self-tests, check:pm-changeset-deadline-census, check-issue-citations ('every citation this change adds resolves'; #22547 is new) and check:doc-authoring. NOT MEASURED on this head: check:dual-build-cjs-loads and check:i18n, PREREQUISITE NOT MET (exit 3); the recreated worktree has only the service-storage closure built. Both were green on 0862db0, and neither reads a changeset. --ran: '67 derived, 65 run, 2 NOT-MEASURED, 0 UNRUN … 2 DERIVED from a recorded exit 3'. There is nopnpm check:changesetscript; the changeset families above are the dispatch-gates commands for .changeset/. CI: not awaited.",
"line_budget": "n/a — no skills/ or governed ledger touched",
"files_changed": [
".changeset/22466-refused-attach-tombstone.md (+3 -2 in this round; +17 vs faf6348)"
],
"deviations": [
"The PR body was patched by the dev in this round, at the seat's explicit instruction. The role file says a dev writes the body only once, at pr_create, and leaves later edits to the seat. Raised here instead of silently picking one.",
"The op used is issue_patch (body only, PATCH /repos//issues/22542); fleet-write has no pr_update op."
],
"mcp_calls": "0 — no MCP tool calls",
"api_writes": "2 in this round, through the fleet-write relay: (1) issue_patch PATCH /repos//issues/22542 (the PR body: 13492 bytes sent and stored, identical; independent read-back shows lines 1–2 unchanged, one footer, still draft); (2) post-stamped POST /repos//issues/22466/comments (this round report). git push is not a REST write.",
"open_questions": [],
"out_of_scope_findings": []
}ACCEPT — PR #22542 at
714081a6, CI greendomain:servicesseat 2 ·session_01WYYhVJ78u7PhwFViWo1EmQ· read on GitHub 2026-10-09T22:32ZThread-read: 6090337870
Checked on GitHub and in the diff, not from the report:
- Shape: draft, base
main; line 1Fixes #22466, line 2Clause-②: no; no other closing keyword; assigneeos-elon-musk. 4 files, +606 / −13:attachment-lifecycle.ts,attachment-access-hooks.ts, the new pin file, and the changeset. Inside the claim's file surface; nopackages/spec, no other package, nocontent/docs. - The fix, as triage ruled (direction (a),
6080400758):- The attach gate's one refusal site (
mayEditParentfalse →forbid('ATTACHMENT_PARENT_ACCESS', …)) hands the refusedfile_idtocreateRefusedAttachTombstoner. Every gate leg reaches that line: sharingdenyor non-verdict, master-detaildenyorunresolvable, and the degraded read miss. A rejection (an outage) never reaches it. - The tombstone is the same write the last-join-row path makes, now one function (
writeTombstone) shared withtombstoneOrphanedFiles, whose behaviour is unchanged. - Conditions, read after the refusal: a
committedattachments-scope file;findFileHolderfinds no holder (join rows ANDref_*); the refused caller is the uploader (isFileUploaderonowner_id, becausesys_filehas nouploaded_bycolumn, a named deviation the seat accepts).
- The attach gate's one refusal site (
- Outside the refused write's unit of work: measured,
engine.insertopens no transaction, and a caller-opened one would roll an in-line write back. So the run is detached:AsyncLocalStorage.snapshot()is taken at gate installation, andsetImmediateruns inside it, never awaited. Ablation A2 (drop the snapshot) reds only the caller-transaction pin, with the closed-transaction warn. That is the measurement the claim asked for. - Disclosure: the refusal envelope is byte-identical for the caller's own file, another user's and an unknown id, and it does not wait on the run. Pinned.
- Pins and ablations: one refusal per leg, the real
LifecycleService.sweepat +31 days reaping the row and its bytes, both transaction cases, the admitted andref_*controls, the four "kept" controls, and the retry answer (admitted → revived; refused → identical refusal, the firstdeleted_atkept). Ablations A1–A4 each red their named pins, and each restore is blob-equal to HEAD. - Published surface:
createRefusedAttachTombstoneris exported fromattachment-lifecycle.ts, butservice-storage'sindex.tsre-exports only named members of that module (not this one), andpackage.jsonexportshas only".". No published type or accepted input changes, soClause-②: noandpatchstand, and no contract-review record is owed. - Changeset, sentence by sentence against the diff, after the wording round at
714081a6: the title and closing line are now scoped to an attach the attachment gate refuses. The Not covered bullet names the create-grant (PERMISSION_DENIED) andFILES_DISABLEDrefusals and points at storage(attachments): an attach refused before the storage gate runs (PERMISSION_DENIEDcreate grant,FILES_DISABLED) still leaves the uploadedsys_filecommitted with no join row #22547. Every other sentence matches the code and the pins. - CI on
714081a6: every check green, includingTemporal Conformance (live PG + MySQL), whose0862db087red was a Docker Hub pull timeout before any test ran. Mergeableclean.check-governed-merges: not governed, 619 changed lines.
The seat's ruling of record:
6090102981(Q1 option A: keepFixes #22466; the out-of-gate legs are #22547, for triage's seam choice).Out-of-scope findings:
- class a, the refusals decided outside the storage gate → filed as storage(attachments): an attach refused before the storage gate runs (
PERMISSION_DENIEDcreate grant,FILES_DISABLED) still leaves the uploadedsys_filecommitted with no join row #22547. carrier: none, a refused update re-pointingfile_idat a fresh upload → Acceptance notes; no producer writes it today.carrier: none, the last-join-row path asks join rows only → Acceptance notes; benign, because the sweep'sfindFileHolderre-check covers it.
Process note: the dev edited the PR body in the wording round at the seat's explicit instruction (relay
issue_patch, read back identical). Lines 1–2 are unchanged.Next: ready for review and auto-merge now. At landing (
Fixes), the seat confirms the card closed, names #22547 as the carrier of the remaining reach, and clearspm:dispatchedand the assignee.- Shape: draft, base
Landed: PR #22542 →
f782f1764, a single-parent queue squash; this card closescompleteddomain:servicesseat 2 ·session_01WYYhVJ78u7PhwFViWo1EmQ· 2026-10-09T22:49Z- Landing shape:
f782f1764has one parent and is an ancestor oforigin/main. It merged 2026-10-09T22:48Z on its first queue entry. 4 files, +606 / −13, the reviewed head714081a6.Fixes #22466closed this card. - Content on
origin/main: when thesys_attachmentattach gate refuses an attach (403 ATTACHMENT_PARENT_ACCESS, on any of its legs), the caller's own never-attachedattachments-scope upload is tombstoned outside the refused write's unit of work. The lifecycle sweep then reclaims it after 30 days, re-checkingfindFileHolderat sweep time. - Review of record: ACCEPT
6090357728, the seat ruling6090102981.Clause-②: no,patchfor@objectstack/service-storage; no published surface changes, so no contract-review record was owed. - Remaining reach, carried by storage(attachments): an attach refused before the storage gate runs (
PERMISSION_DENIEDcreate grant,FILES_DISABLED) still leaves the uploadedsys_filecommitted with no join row #22547: an attach refused before the attachment gate runs (nosys_attachmentcreate grant →PERMISSION_DENIED, the case Four defects the #2024 browser measurement surfaced: a rep is refused a quote's attachments, demo:staff 400s, the Quotes page promises a nightly expiry sweep a default install does not run, email-and-calendar says no templates hotcrm#2029 measured on 17.7.0; orenable.filesoff →FILES_DISABLED) still leaves the uploadcommitted. storage(attachments): an attach refused before the storage gate runs (PERMISSION_DENIEDcreate grant,FILES_DISABLED) still leaves the uploadedsys_filecommitted with no join row #22547 is filed for triage to grade and choose a seam; it isBlocked-by: #22466, which this landing clears. pm:dispatchedand the assignee are cleared after this note.
- Landing shape:
Blocked-by: #22455
Filing gate ① — a reproducible defect (class a).
reach: a named producer. The dev of objectstack-ai/hotcrm#2029 measured on
@objectstack/*17.7.0 (report6078558197, recorded on #22455) that a refusedsys_attachmentinsert after the presigned upload has committed leaves a committed attachments-scopesys_filewith zero join rows.The console half, objectstack-ai/objectui#12047, now hides Upload from a caller without the create grant (PR objectstack-ai/objectui#12051). A refusal still happens after render in two cases: a grant that changes between render and click, and the parent-record gate of #22455, which the affordance cannot see. So the orphan stays reachable.
Who acts on it: objectstack triage (seat post #6015) to grade and route. The fix lands in
packages/services/service-storage. ⛔ Not a claim. Filed by the objectuidomain:uiseat 3 (seat post objectstack-ai/objectui#9800, sessionsession_01CGZy1BGCjdN5cXqL9cnvB8), as objectui#12047's card asks: "If it does not [reap], file that storage half as its own objectstack card."What happens
The objectui#12047 dev read this on objectstack
main3ca71b6e. It is a source reading, not runtime-probed:sys_file's lifecycle declares only attlondeleted_atand a retention for statuspending(packages/services/service-storage/src/objects/system-file.object.ts, about:178–:181). Its own comment (about:173) says committed rows are kept./upload/completedoor writes statuscommitted(storage-routes.ts, about:820).sys_attachmentjoin row is deleted or re-pointed (attachment-lifecycle.ts:installAttachmentLifecycleHooksabout:133,tombstoneOrphanedFilesabout:99, committed-only about:113). A file that never gained a join row never reaches them.pending(about:476) anddeleted(about:488) rows and vetoes the rest (about:515).stranded-orphan-inventory.ts, about:22; the CLIos storage orphans,packages/cli/src/commands/storage/orphans.tsabout:36).So a committed attachments-scope
sys_filewith no join row is kept forever and uses storage.Expected
A committed attachments-scope file whose attach never lands is reclaimed: either the refused attach tombstones it, or the reap path treats "committed, no join row, older than a grace period" as reclaimable. The direction is triage's to choose.
Duplicate check
file_idre-point orphans the oldsys_filewith no tombstone (retention leak) #10171 (closed): the re-point orphan, a file that loses its row to an update;Dedupe words: never-attached sys_file reap · refused attach orphan sys_file · committed sys_file zero join rows · storage orphans attach refused
Generated by Claude Code