?recordId= carries no object, so a form action fired from the wrong object can edit a same-id record in the target object #4292

Found while implementing #4278 (which makes /forms/:name?recordId= load and PATCH that record). Filed unassigned for triage; deliberately not fixed there — the producer side is packages/core/src/actions/ActionRunner.ts, which #4278's ruling put out of scope and which #4046 currently holds.

What is missing

ActionRunner.executeForm forwards only the record id:

const recordId =
  (this.context.record && (this.context.record as { id?: unknown }).id) ??
  (this.context.data && (this.context.data as { id?: unknown }).id);
const base = `/forms/${name}`;
const to = recordId != null ? `${base}?recordId=${encodeURIComponent(String(recordId))}` : base;

Nothing in that URL says which object the id belongs to. The consumer therefore has to pick one, and the only sane choice is the FormView's own target object — which is what #4278 implements: it reads GET /api/v1/data/:object/:id with the view's object, and writes PATCH /api/v1/data/:object/:id to the same.

That is correct whenever the action was fired from a record of the view's target object. Nothing enforces that it was. An action's locations bind it to a record surface, but the target FormView's object is authored independently, so target: 'showcase_task.edit' on an Account record header is publishable metadata today.

Why it can be silent

Two outcomes when the fired-from object and the view's target object differ:

• ids do not collide (uuid / prefixed keys): the read finds nothing under the view's object, 404s, and type: 'form' action fired from a record opens an empty CREATE form — /forms/:name ignores the ?recordId= ActionRunner forwards #4278's fail-closed path renders the error state. Fine — loud, and the user is told.
• ids DO collide (integer / per-table sequential primary keys, which several drivers produce): GET /api/v1/data/showcase_task/42 happily returns Task 42 while the user was looking at Account 42. The form prefills Task 42's values and, on submit, PATCHes Task 42. No error, no warning, and the record the user was actually on is untouched.

The consumer cannot detect this. The server echoes the path object back (getData returns object: request.object), so the response looks perfectly valid — #4278 pins an object-mismatch guard at the consumer and documents that a live packages/rest deployment cannot trigger it for exactly this reason.

Why it is worth grading now rather than before

Pre-#4278 the same ambiguity existed but the blast radius was smaller: the route ignored recordId entirely, so a mis-scoped action produced an empty form and an INSERT. Now that the route honours the param, the same mis-scoped action produces a targeted UPDATE of a different object's record. The fix made the surface correct; it also made this hole worth naming.

Options a fix would choose between

Not obvious enough to guess — hence filed rather than fixed:

1. Forward the object too (?recordObject= alongside recordId) and have the form route refuse when it disagrees with the view's target. Closes it at both ends, but adds a URL param to the console's reserved contract (app-shell/src/urlParams.ts).
2. Validate at the producer: executeForm resolves the target view's object and refuses to navigate when the context record's object differs. No new URL surface, but it makes ActionRunner a metadata reader it currently is not.
3. Validate at publish time: reject a type: 'form' action whose locations put it on an object other than its target view's. Structurally prevents the mis-authoring instead of catching it at runtime — the "make AI-written metadata hard to get wrong" direction — but only covers statically-placed actions.

Measured on

origin/main at 90e792e11 plus the #4278 branch, by reading ActionRunner.executeForm, packages/metadata-protocol/src/protocol.ts (getData echoes object: request.object), and the data plugin's route table in @objectstack/spec api/plugin-rest-api.zod.ts. Not browser-verified; the id-collision half depends on the deployment's primary-key strategy.

Generated by Claude Code