You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Backfill the stranded org-less platform rows the #10101 writers no longer produce: pending sys_approval_request rows still lock records invisibly; sys_automation_run history stays unattributed #11308
Filed unassigned by the #10101 services seat (session session_01APWX2AwT3a4xDcjPCe8bk4) — this is the #10131 backfill question, explicitly declined in the #10101 PR with this card as the reason rather than dropped (the #10101 dispatch required an explicit answer either way).
The stranded population (measured on cloud#1395)
9/9sys_approval_request rows with organization_id IS NULL naming a subject record that HAS an organization — plus their sys_approval_action / sys_approval_approver rows stamped from the same null.
12/12sys_automation_run rows in the same shape.
#10101 fixes the WRITERS (subject-first through the shared resolver in @objectstack/metadata-core); it writes nothing to existing rows, so the stranded population persists after it lands.
What the stranded rows cost
A pending org-less sys_approval_request keeps the measured cloud#1395 harm alive for itself: it locks the record it is about while being invisible in every org-scoped inbox (its owner's included). The in-product recovery today is the Approval routed to an empty position permanently locks the record (no admin override, no recovery) #3424 privileged-admin override, per request, by hand. This is the half with real ongoing harm.
Terminal sys_automation_run rows are observability-only AND age out on their own: the object declares retention: { maxAge: '30d', onlyWhen: status in [completed, failed] }, so the measured 12 disappear within a month regardless. Paused rows (live resumable state) keep NULL until resumed-and-resuspended; resume itself does not key on the column.
A backfill writes to existing production rows — its own blast radius (idempotency, organization_id IS NULL guard, subject-record re-read at repair time, rows whose subject has since been deleted), riding a contract-review-tier behaviour change. The #8617 precedent in the same plugin included a reap, so the shape is sanctioned; the bundling was the problem.
Suggested shape (measurement wins)
A bounded, idempotent repair sweep for sys_approval_request (pending rows first — the harmful half), resolving each row's subject organization through the SAME shared resolver (createRecordOrganizationResolver, @objectstack/metadata-core) — ⛔ never a second resolution — and updating the request + its action/approver rows together ("all three move together"). Decide explicitly whether the automation paused-row half is worth taking given the retention facts above; the terminal half likely is not.
Blocked-by: the #10101 PR (the shared resolver export must be on main).
Filed unassigned by the #10101 services seat (session
session_01APWX2AwT3a4xDcjPCe8bk4) — this is the #10131 backfill question, explicitly declined in the #10101 PR with this card as the reason rather than dropped (the #10101 dispatch required an explicit answer either way).The stranded population (measured on cloud#1395)
sys_approval_requestrows withorganization_id IS NULLnaming a subject record that HAS an organization — plus theirsys_approval_action/sys_approval_approverrows stamped from the same null.sys_automation_runrows in the same shape.#10101 fixes the WRITERS (subject-first through the shared resolver in
@objectstack/metadata-core); it writes nothing to existing rows, so the stranded population persists after it lands.What the stranded rows cost
sys_approval_requestkeeps the measured cloud#1395 harm alive for itself: it locks the record it is about while being invisible in every org-scoped inbox (its owner's included). The in-product recovery today is the Approval routed to an empty position permanently locks the record (no admin override, no recovery) #3424 privileged-admin override, per request, by hand. This is the half with real ongoing harm.sys_automation_runrows are observability-only AND age out on their own: the object declaresretention: { maxAge: '30d', onlyWhen: status in [completed, failed] }, so the measured 12 disappear within a month regardless. Paused rows (live resumable state) keep NULL until resumed-and-resuspended; resume itself does not key on the column.Why declined from the #10101 PR
A backfill writes to existing production rows — its own blast radius (idempotency,
organization_id IS NULLguard, subject-record re-read at repair time, rows whose subject has since been deleted), riding a contract-review-tier behaviour change. The #8617 precedent in the same plugin included a reap, so the shape is sanctioned; the bundling was the problem.Suggested shape (measurement wins)
A bounded, idempotent repair sweep for
sys_approval_request(pending rows first — the harmful half), resolving each row's subject organization through the SAME shared resolver (createRecordOrganizationResolver,@objectstack/metadata-core) — ⛔ never a second resolution — and updating the request + its action/approver rows together ("all three move together"). Decide explicitly whether the automation paused-row half is worth taking given the retention facts above; the terminal half likely is not.Blocked-by: the #10101 PR (the shared resolver export must be on
main).Refs: #10101 · #10131 (the original filing, closed as duplicate of #10101) · cloud#1395 · #3424 · #8617.