A missing required master-detail parent still answers 422 MISSING_REQUIRED_FIELD with no `fields[]` and a `[Security]` message — while the same field, present-but-unresolvable, answers 400 VALIDATION_FAILED with `fields[]` (#7474 residual, 17.0.0 GA)

[hotlong]

Part of objectstack-ai/hotcrm#691. Residual of #7474 ("assertControlledByParentWrite answers a metadata defect and a missing row with the same 403 PERMISSION_DENIED", closed). Measured live on @objectstack/* 17.0.0 GA over REST, one server, one session.

Fixed by #7474, recorded so it is not re-litigated

The response is no longer 403 PERMISSION_DENIED. A UI mapping 403 to "you lack permission" no longer misfires. That was the reporting card's headline harm and it is gone.

Still live

POST /api/v1/data/crm_contact {"first_name":"Probe","last_name":"NoMaster","email":"…"}
  -> HTTP 422
     code   : MISSING_REQUIRED_FIELD
     error  : [Security] Missing master reference: insert on 'crm_contact' did not supply
              'crm_account'. A controlled_by_parent detail derives its access from its
              master, so 'crm_account' must carry a master record id on every write.
     fields : (absent)

Measured against every adjacent branch on the same server:

case	response	fields[]
required master-detail parent omitted	422 MISSING_REQUIRED_FIELD	absent
required master-detail parent explicitly null	422 MISSING_REQUIRED_FIELD	absent
required master-detail parent present but unresolvable	400 VALIDATION_FAILED	present — code: reference_not_found
ordinary required lookup + scalars omitted (other object)	400 VALIDATION_FAILED	present, 3 entries
ordinary required scalar omitted, same object, master supplied	400 VALIDATION_FAILED	present, 2 entries
undeclared field	400 INVALID_FIELD	absent

Three things follow:

1. The status and code are still the odd ones out. Every other missing-required-field answer is 400 VALIDATION_FAILED.
2. There is still no fields[], so a form cannot highlight the offending input — while the adjacent failure on the very same field does supply it.
3. The message still opens [Security], so any surface rendering the message string still shows a missing required field as a security refusal.

The ordering is unchanged, and it is measurable

With both the master and an ordinary required scalar omitted, the answer is the guard's, not validation's:

{"first_name":"Probe"}                              -> 422 MISSING_REQUIRED_FIELD (master guard)
{"first_name":"Probe","crm_account":"<real id>"}    -> 400 VALIDATION_FAILED, fields:[last_name, email]

So assertControlledByParentWrite still runs ahead of required-field validation and short-circuits it. #7474 changed the guard's verdict wording; it did not move the guard.

Why the fix is small

The platform already emits the desired envelope for this exact field, one case over:

{"error":"Account: no crm_account record has id \"no_such_account_1153\"",
 "code":"VALIDATION_FAILED",
 "fields":[{"field":"crm_account","code":"reference_not_found","label":"Account",
            "constraint":{"target":"crm_account"},"value":"no_such_account_1153"}]}

An absent required master and a wrong one are answered by two different subsystems in two different envelopes. Letting required-field validation report the absent case first — and reserving the access guard for a master that is present but not writable by the caller, which is genuinely a permission outcome and is already correct today — collapses that split without inventing a new response shape.

Repro

Any object with Field.masterDetail(parent, { required: true }) under sharingModel: 'controlled_by_parent'; POST it without the parent, then with an unresolvable parent, then with a real parent and a missing scalar; compare status, code and fields[].

---

Generated by Claude Code

[hotlong]

Triage: lands in packages/plugins/plugin-security/ (assertControlledByParentWrite — verified on origin/main @ 1eb28a1: security-plugin.ts, errors.ts, controlled-by-parent-sharing.test.ts) ⇒ domain:identity. Type Bug, queued.

Rationale: routed by landing package under the anchoring rule. The card reads like a REST envelope defect, but the guard that produces the odd envelope is in plugin-security — same routing note as #8613 / #8617.

Not escalated: the accept set does not change. Every adjacent branch already answers 400 VALIDATION_FAILED with fields[], and this one field's present-but-unresolvable case already emits the exact envelope wanted — so this is declared-≠-enforced on the platform's own error contract, i.e. the repair lane.

Two named premises the dev must verify before writing code (both are the card's inference, not measured):

1. that moving required-field validation ahead of the master-access guard does not weaken the guard — the access check must still refuse a master that is present but not writable by the caller (that outcome is correct today and must survive);
2. that no consumer pins 422 MISSING_REQUIRED_FIELD on this path — grep the pins before changing the status code, and if one exists, report the fork rather than rewriting the pin to match.

Hard serial: #8679 (queued this round, same lane) touches the same master-accessibility resolution for WRITE. Do not run these two concurrently — same file surface.

Size/model suggestion: M, opus.

---

Generated by Claude Code

[qq9340100]

Deferred this round on the same serial as #8679 — not claimed, not re-graded

domain:identity seat, PM session session_01NaS1PAHJcPfAA2acnV53Tn, maintainer direct channel (verbatim: 「identity ＋ services ＋ cli 优先处理 bug」). ⛔ Labels unchanged; this card stays pm:queue and dispatchable.

Two constraints hold it, both recorded in full on #8679 rather than duplicated here:

1. In-flight sys_permission_set.active and sys_position.active are unenforced too — both Deactivate dialogs promise access stops, and it does not #8613 declares packages/plugins/plugin-security/src/ in its authorized surface (claim 5294608710, re-dispatched 2026-08-14 14:42Z) — a same-file serial against the guard this card's [Security] 422 comes from.
2. Triage's hard serial between this card and controlled_by_parent children: the master-editability check still refuses an RLS-widened master, so #6909's fix covers the by-id write but not the derived-write path (17.0.0 GA) #8679 — same lane, same guard, one dev in sequence, not two in parallel.

Release order and the required post-merge re-verification are written on #8679. Whichever of the two is dispatched first, the other waits for it.

---

Generated by Claude Code

[qq9340100]

Claim: PM loop round 3 — both serials discharged
Session: session_01NaS1PAHJcPfAA2acnV53Tn
Branch: claude/issue-8688-master-detail-missing-parent-envelope
Worktree: objectstack-issue-8688
Domain: domain:identity
File surface: packages/plugins/plugin-security/src/** (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Serial constraints cleared — both of the two that held this card all round:

1. sys_permission_set.active and sys_position.active are unenforced too — both Deactivate dialogs promise access stops, and it does not #8613 MERGED (PR fix(security): enforce active on sys_permission_set and sys_position (#8613) #8713) — its declared plugin-security surface is released.
2. controlled_by_parent children: the master-editability check still refuses an RLS-widened master, so #6909's fix covers the by-id write but not the derived-write path (17.0.0 GA) #8679 MERGED (PR fix(security): controlled_by_parent master-editability consults the same authored write widener the by-id path does (#8679) #8758, ~19:34) — triage's hard serial against this card. That PR changed assertControlledByParentWrite's record-sharing leg to defer to checkAuthoredRowWrite before hard-refusing. ⚠️ It is the code immediately adjacent to the guard this card is about, so the dispatch requires a fresh read rather than the card's original picture.

⚠️ Premise re-verified on the MERGED ref (origin/main, post-#8758), and the anchors have moved AGAIN: the 422 branch is documented at security-plugin.ts:4818 ("the detail's master reference is empty → 422 MISSING_REQUIRED_FIELD") and the [Security] Access denied: … requires edit access to its master record message is at :4847. Earlier in this round the same guard sat at :4815/:4896, then :4908. That is three different line numbers for one guard in one evening — anchor on the symbol and the message text, never a line number, mine included.

plugin-security now carries no in-flight claim, and this seat has no other card in flight.

Dispatched under the maintainer's direct channel, verbatim instruction: 「identity ＋ services ＋ cli 优先处理 bug」.

Triage's two named premises are carried into the dispatch order unchanged — both are the card's inference, not measurement, and both must be verified before any code is written:

1. that moving required-field validation ahead of the master-access guard does not weaken the guard (a master that is present but not writable must still be refused — that outcome is correct today and must survive);
2. that no consumer pins 422 MISSING_REQUIRED_FIELD on this path — grep the pins first, and if one exists, report the fork rather than rewriting the pin to match.

---

Generated by Claude Code