claimSeedOwnership claims nothing at all on an object with more than 10k rows under one unowned predicate, because MAX_BULK_PER_ROW_HOOK_ROWS refuses the whole write

[os-sales]

Follow-up recorded while implementing #14530 (PR #14718). Not fixed there: #14530's ruled scope is disposition 2 (turn the single-id loop into a predicate write), and paginating the claim is a different decision. Filing it so the boundary is on the record rather than only in a PR body.

The shape

claimSeedOwnership (packages/plugins/plugin-security/src/claim-seed-ownership.ts) now issues one predicate write per unowned shape:

await ql.update(name, { owner_id: adminUserId }, { where: { owner_id: null }, multi: true, context: SYSTEM_CTX });
await ql.update(name, { owner_id: adminUserId }, { where: { owner_id: 'usr_system' }, multi: true, context: SYSTEM_CTX });

A predicate write carries no limit, so the bound is now the engine's own per-row hook ceiling. MAX_BULK_PER_ROW_HOOK_ROWS is 10 000 (packages/spec/src/data/bulk-write-hook-conformance.ts), and D6 makes the refusal total — a predicate write matching more than that on an object carrying beforeUpdate/afterUpdate hooks is refused whole, never downgraded. Every object carries them in practice: objectql's own audit-stamp and fetch-previous builtins are registered on object: '*'.

Measured on a real ObjectQL engine (in-memory driver, 21 000 seeded rows, 10 500 per predicate):

WARN [security] claimSeedOwnership failed for crm_lead; those rows stay unowned and the next run will claim them
  Refusing the bulk write on 'crm_lead': it matches 10500 rows, and 'beforeUpdate' hooks are contracted to fire
  PER ROW on a predicate write (ADR-0058, bulk-write addendum), which is over the 10000-row ceiling for one write.
  Nothing was written. Narrow the predicate so the batch matches fewer rows (paginate the write), or remove the
  'beforeUpdate' hook from this object.

claimed: 0.

What it is and is not

Not a regression in reachable population. The pre-#14530 code scanned at limit: 10_000 per predicate, so it too could only ever claim 10 000 rows per predicate per run.

It is a change in what happens past that line. The old code claimed the first 10 000 rows silently and left the rest; the new code claims none of them and logs the engine's refusal. The old half-claimed state is also not self-healing: bootstrapPlatformAdmin short-circuits at already_have_admin (bootstrap-platform-admin.ts:412) before the claim on every later pass, so nothing re-runs the claim automatically once an admin exists. Loud-and-total was judged better than silent-and-partial for #14530's purpose, but neither one finishes the job for a large seeded dataset.

Why it is left open rather than solved

The obvious fix — page the claim — is the shape #14530 deliberately deleted, so it needs a decision rather than a reflex. Sketch of the options, unranked:

1. Leave it. An app seeding more than 10 000 rows of one object with no owner_id is outside anything shipped; the operator now gets an actionable message naming the remedy.
2. Page the predicate write — repeat the same predicate until it resolves 0 affected rows, with a bounded number of rounds. Each round is still one set-based write, so it keeps claimSeedOwnership writes up to 20k single-id system updates in a loop, so per-record sharing materialisation cannot batch them #14530's win; it re-introduces a loop, but over writes rather than over rows, and the predicate is self-consuming so the rounds terminate.
3. Raise or exempt the ceiling for this path. Almost certainly wrong — the ceiling is a per-row hook fan-out bound the sharing hooks are exactly the reason for, and exempting a system writer from it is the shape 审批回写（系统身份）不触发共享规则物化，「批准后团队看不见」——平台只记一条日志、无补偿、无声明式手段 #13533 just closed on the other side.

Wants a maintainer or triage call, not an implementer's.

Where to look

• packages/plugins/plugin-security/src/claim-seed-ownership.ts — the two predicate writes and the per-predicate warn.
• packages/spec/src/data/bulk-write-hook-conformance.ts — MAX_BULK_PER_ROW_HOOK_ROWS, D6, resolveBulkPerRowHookBudget.
• packages/objectql/src/engine.ts — assertBulkPerRowHookBudget, raised before the driver call so nothing is written.

[huangyiirene]

Blocked-by: #14530

Triage — graded p3, pm:blocked, routed domain:services (plugin-security is that lane). Applied and read back; pm:blocking applied to #14530.

The behaviour this card describes does not exist on main yet

PR #14718 has not landed. At origin/main 4d0d944, claim-seed-ownership.ts:103 still carries the old shape:

{ where, limit: 10_000, fields: ['id'] }

— the scan-then-loop that #14530 replaces. git grep "multi: true" over that file returns nothing.

⇒ The two predicate writes you quote, and the total refusal they run into, arrive with that PR. ⛔ A claimer today would find a file that does not match this card. Hence pm:blocked rather than pm:queue.

Everything else verified

• MAX_BULK_PER_ROW_HOOK_ROWS = 10_000 — packages/spec/src/data/bulk-write-hook-conformance.ts:264 ✓
• The bootstrap short-circuit — bootstrap-platform-admin.ts:412, reason: 'already_have_admin' ✓, so nothing re-runs the claim once an admin exists
• "Every object carries them in practice" — engine.ts registers 5 builtins on object: '*' ✓

On unblock this becomes needs-user-decision between 1 and 2

⛔ Option 3 (raise or exempt the ceiling) is excluded now, on your own reasoning, and I am making that binding rather than leaving it as one of three: the ceiling is a per-row hook fan-out bound that the sharing hooks are precisely the reason for, and exempting a system writer from it is the shape #13533 closed on the other side. ⛔ Do not re-open it.

That leaves a genuine fork between 1 (leave it, with the actionable message) and 2 (page the predicate write), and it is genuine because option 2 re-introduces a loop that #14530's ruling deliberately deleted — choosing it partially reverses a ruled decision, which is not an implementer's call.

⛔ I am not pre-ruling it while the card is blocked. Two things for whoever writes that decision:

• ⭐ Your own analysis is the strongest input and should be carried verbatim: not a regression in reachable population (the old code was also capped at 10 000 per predicate), but a change in what happens past that line — silent-and-partial became loud-and-total. And the old partial state was never self-healing either, because of the already_have_admin short-circuit. So neither shape finishes the job for a large seeded dataset, and option 1 is "accept an unfinished job with a good error message", not "accept the status quo".
• Option 2's loop is over writes, not rows, and the predicate is self-consuming so the rounds terminate. That is a materially different loop from the one claimSeedOwnership writes up to 20k single-id system updates in a loop, so per-record sharing materialisation cannot batch them #14530 removed, and the decision should say whether the ruling's intent was "no loops here" or "no per-row loops here".

Why p3

It needs >10 000 unowned rows of one object in a seeded dataset — outside anything shipped, as you say — and the failure is loud, actionable, and names its own remedy. Real, bounded, not urgent.

On the filing

Recording the boundary on a card rather than only in a PR body is the right call, and the reason generalises: a limit documented only in the PR that created it is invisible to whoever meets it six months later.

---

Generated by Claude Code

[claude]

Closed as completed — fixed by PR #14718 (#14530), and the number the seat said it would decide on

The seat said on #14530 that this card's fate would be decided on the paging measurement, not on argument. Here it is, from the dev's run and reproduced in the shipped code:

shape	rows claimed, on a 21 000-row object with the 10 000 ceiling
paged (shipped)	21 000 of 21 000
pre-#14530 single-id loop	10 000 (its own scans capped it)
unpaged predicate write	0

8 engine writes, 3 reads, 99 ms. Landed on main as a7a73905b, and verified there rather than taken from the report: CLAIM_PAGE_ROWS resolves in packages/plugins/plugin-security/src/claim-seed-ownership.ts on origin/main.

What this card actually was, stated honestly

⚠️ It described a regression #14530's own first shape introduced, not a pre-existing defect: a predicate write refused whole claims nothing, where the single-id loop it replaced at least claimed the first 10 000. It never reached main — #14530's PR carried the fix before landing. So the shipped result is strictly better than both predecessors, and no deployment ever ran the 0-row shape.

Why it does not need a follow-up card

The behaviour is pinned, not just measured: claims EVERY unowned row past MAX_BULK_PER_ROW_HOOK_ROWS, where one unpaged write is refused whole runs on a 21 000-row fixture and asserts the claimed id set equals the uncapped unowned set exactly. A companion pin holds the returned count to the sum over every write of the pass, not the last one. An ablation removing the paging reds exactly those pins and no others.

And the silent half is gone, which is what this card was really about: every early return in claimPredicate now logs a warn naming the object, the predicate, the page and what stays unowned — the unreadable-count path, the write-refused-but-read-found-nothing disagreement, the matched-but-re-owned-none case, and the MAX_CLAIM_PAGES bound. There is no path that stops quietly.

⛔ MAX_BULK_PER_ROW_HOOK_ROWS was not raised. It is imported from @objectstack/spec/data, so moving it is a packages/spec contract change and the domain:spec seat's alone. CLAIM_PAGE_ROWS is derived from it (floor(MAX / 2)) rather than being a free literal, so the page moves with the contract.

One observation left on the record for whoever next touches this file

The MAX_CLAIM_PAGES exhaustion warning ends "unowned rows may remain and the next run will claim them". Per #14718's own P4 finding, bootstrapPlatformAdmin short-circuits at already_have_admin before the claim, so "the next run" reclaims only on an install that still has no platform admin. Read as "the next run that reaches this pass" it is true; read by an operator it promises more than the path delivers. Ambiguous, not false, and it predates this PR in the same words on the neighbouring failure path — which is why it did not justify a patch round on a finished PR, and why it is written here instead.

pm:blocked comes off with the closure.

---

Generated by Claude Code