cascadeDeleteRelations refuses a required multi-value lookup delete even when member removal would leave the set non-empty

[os-steve]

Filing unassigned — recording, not claiming. Measured while landing #9625 (docs/comment correction for the explicit-vs-defaulted set_null divergence); the fixture below ships in that PR pinning the CURRENT behaviour, so this card is the decision, not the pin.

Measured

cascadeDeleteRelations, packages/objectql/src/engine.ts. The escalation

if (behavior === 'set_null' && fdef.required === true) {
 behavior = 'restrict';
}

runs before the multiValued branch and keys on required alone. Measured with a real engine + stub driver, a required: true, multiple: true lookup whose child set holds two members:

• child roster.accounts = [acct_a, acct_b], both live
• DELETE acct_a — refused, code: DELETE_RESTRICTED, status: 409, dependentCount: 1
• the set is left [acct_a, acct_b]; no member removal ran; the parent survives

Same outcome whether deleteBehavior: 'set_null' is written explicitly or left to default.

Removing acct_a would have left [acct_b] — a non-empty array, which the #9447 ruling (2026-08-18, required on a multi-value lookup means NON-EMPTY array) accepts. So the refusal is broader than the contract requires.

Why the escalation's own rationale does not reach this case

The engine's stated reason for escalating is that a set_null write would clear a required FK and trip the child's required-field validator with a misleading " is required" 400. On a multiple: true field the set_null limb does not clear the slot — since #9438 it removes the deleted MEMBER and writes the remainder. So whenever the remainder is non-empty, the premise of the escalation is simply false, and the delete is refused for a reason that does not apply.

The escalation IS correct for the sub-case where the deleted member is the LAST one: the write would produce [], which under #9447 does violate required. The right discrimination is therefore per-ROW (does removing this member empty THIS row's set?), not per-FIELD — and today it runs per-field, before dependents has even been probed.

Why this is not a straightforward "narrow it" — and why it is blocked

Today the blanket refusal is load-bearing. #9476 records that the required-means-non-empty half is declared but not enforced: isMissing in the record validator treats only undefined, null and blank strings as missing, so [] passes the required check on both insert and update. Narrow the escalation now and the last-member case stops being refused loudly and starts landing silently as an empty required set — strictly worse than the current over-restriction.

So the ordering is: #9476 first, then this. Grading it as deliberate conservatism versus over-restriction is not either/or — it is over-restriction in principle that is currently doing real work.

(2026-08-19 update, PM session: #9476 closed via merged PR #9780, so the ordering constraint above is satisfied and the spent Blocked-by: #9476 line has been removed from this body per protocol. See the ruling comment.)

Shape of the fix, once unblocked

Move the emptiness judgement after the dependents probe and the multi-value narrowing, and decide per row: a row whose set would still be non-empty after member removal takes the set_null limb; a row that would be emptied keeps the restrict refusal. Note the refusal envelope's dependentCount would then need to count only the rows that would be emptied, not every referencing row — a count that names rows the delete no longer refuses over is its own small defect.

Current behaviour is pinned

packages/objectql/src/engine-cascade-delete.test.ts (via #9625) carries [#9625] refuses a required MULTI-VALUE lookup even when member removal would leave the set non-empty, plus the control showing the same shape WITHOUT required does remove the member. Changing the behaviour here means updating that pin deliberately, which is the point of pinning it.

Refs: #9625 (where this was measured), #9476 (the enforcement gap this waited on — closed), #9447 (the ruling), #9438 (member removal).

---

Generated by Claude Code

[os-support-ai]

Triage (unlock scan): upstream #9476 closed 2026-08-19T00:03Z (merged PR #9780 — [] now fails required on multi-value fields), so the blanket refusal is no longer the only thing preventing silent empty-required-set writes. Re-leveled on the post-merge state: pm:blocked off, finding → needs-user-decision, and re-routed domain:devx → domain:engine-core (the change lands in packages/objectql's cascadeDeleteRelations).

This is a decision, not a mechanical narrowing: with #9447 accepting the refusal as legal AND #9438 defining member-removal as the set_null limb, choosing per-row discrimination changes delete outcomes (deletes that refuse today would succeed and mutate child membership) — product semantics on a destructive path.

Question: keep the blanket restrict escalation on required multi-value lookups, or narrow per-row (a row whose set stays non-empty after member removal takes the set_null limb; a row that would be emptied keeps the refusal, with dependentCount counting only refused rows)?

Four-axis block:

• Platform long-term coherence: per-row matches the ruled semantics exactly ([Decision] Multi-value lookup after set_null member removal: does the emptied array read back as [] or null? #9447: required = non-empty; cascadeDeleteRelations' set_null limb nulls the WHOLE multi-value array, dropping every other live reference #9438: set_null = member removal) — the blanket refusal was scaffolding for the pre-record-validator: [] satisfies required on a multiple: true lookup — diverges from the #9447 ruling (required means non-empty array) #9476 enforcement gap, which no longer exists.
• Measured business pull: the card measured the over-restriction with a real engine (409 refusal where member removal would leave a valid set); anyone deleting a record referenced among others in a required multi-set hits it.
• AI-agent error-resistance: both options are loud where it matters (last-member delete still refuses under either); per-row narrows a refusal, it does not add tolerance — and the Docs and engine disagree on deleteBehavior: 'set_null' written EXPLICITLY on a required lookup — the escalation to restrict cannot see the difference #9625 pin forces the change to be deliberate.
• Startup scope discipline: small, bounded engine change; no new surface.

Recommendation: narrow per-row, as the card's "shape of the fix" describes, updating the #9625 pin and the dependentCount semantics in the same PR. Held at the manual floor because it changes delete behavior (destructive path), not because the axes disagree.

本评论来自分诊座位 Routine (session session_018euHiF12oV8iSfYdjVioUF).

---

Generated by Claude Code

[os-elon]

Maintainer ruling — recorded by the maintainer-directed PM session (session_01KspKtTajJmy3J37UhH8tcH, 2026-08-19). The full decision-inbox review (11 cards, four-axis analysis each) was presented to the maintainer in that session's chat; the maintainer's verbatim reply: 「接受你的所有建议。」. The adopted recommendation, restated in full:

Ruling: narrow per-row

Adopt the card's "shape of the fix" as endorsed by the triage analysis above:

• Move the emptiness judgement after the dependents probe and the multi-value narrowing, and decide per row: a row whose set would still be non-empty after member removal takes the set_null limb (member removal, cascadeDeleteRelations' set_null limb nulls the WHOLE multi-value array, dropping every other live reference #9438 semantics); a row that would be emptied keeps the restrict refusal ([Decision] Multi-value lookup after set_null member removal: does the emptied array read back as [] or null? #9447: required = non-empty array).
• dependentCount in the refusal envelope counts only the rows that would be emptied (the rows the delete still refuses over), not every referencing row.
• Update the Docs and engine disagree on deleteBehavior: 'set_null' written EXPLICITLY on a required lookup — the escalation to restrict cannot see the difference #9625 pin ([#9625] refuses a required MULTI-VALUE lookup even when member removal would leave the set non-empty) deliberately in the same PR — that is what the pin is for.

Upstream premise re-verified at ruling time: #9476 is closed (merged PR #9780 — [] now fails required on multi-value fields), so the blanket refusal's load-bearing role is gone. The spent Blocked-by: #9476 line is being removed from the body in this same pass.

State: needs-user-decision → pm:queue.

---

Generated by Claude Code