finding: the insert-path `readonly` strip is a protocol-boundary guard only — `engine.insert` applies none of it, and `create_record`'s `onFieldsDropped` channel can never fire for a readonly drop

[os-warren]

Observation from an application (objectstack-ai/duly), filed for triage rather than as a defect — the asymmetry may be intended, but the engine's own prose says otherwise and one consumer is wired for a signal it cannot receive.

Measured against @objectstack/runtime 17.2.0 / @objectstack/objectql 17.2.0 / @objectstack/metadata-protocol 17.2.0, on a real booted kernel with the in-memory driver.

What was measured

duly_task.completed_at is readonly: true.

write face	context	forged completed_at
MetadataProtocolService.createData	none	stripped (row then refused by a validation rule)
MetadataProtocolService.createData	{ isSystem: false }	stripped
MetadataProtocolService.createData	{ isSystem: true }	preserved (intended — the documented exemption)
engine.insert (the data service)	none	preserved

The last row is the finding: a non-system caller reaching engine.insert directly writes the read-only column, with no refusal, no WARN, and no onFieldsDropped event.

Why it happens

The insert-path strip is stripReadonlyForInsert, which lives in @objectstack/metadata-protocol and is called from exactly two places — MetadataProtocolService.createData and cloneData:

function stripReadonlyForInsert(schema, data, context) {
  if (context?.isSystem) return data;
  ...
}

The update path is not like this: stripReadonlyFields is inside ObjectQL and runs on every engine.update, isSystem-gated. So readonly is enforced in-engine on update and only at the API boundary on insert.

Two things that look unintended

1. The engine's own doc comment claims otherwise. assertReferencesResolve in objectql/dist/core.js describes its non-system scoping as being

like every other write-path guard in this engine (stripReadonlyFields, stripReadonlyForInsert).

stripReadonlyForInsert is not in that engine and is not on engine.insert's path at all. An application author reading that reasonably concludes the engine enforces readonly on insert.

2. create_record is wired for a drop event it can never get. The automation engine's create_record executor (@objectstack/service-automation) calls data.insert — the engine, not the protocol — and passes onFieldsDropped, then surfaces the result as output.droppedFields and node warnings:

const created = await data.insert(objectName, fields, {
  context: dataCtx,
  onFieldsDropped: (e) => { dropped.push(e); }
});

Since no readonly strip runs on that path, that channel cannot report a readonly drop. A flow without runAs: 'system' can set a readonly column at insert and the run reports a clean success.

(In the application that found this, the relevant flow does declare runAs: 'system', so nothing there is currently affected — this is reported as a seam, not an incident.)

The question for triage

Is the insert-side strip deliberately a user-context / API-boundary concern (which #3425's framing suggests), with engine.insert trusted by construction? If so the fix is prose plus the dead onFieldsDropped wiring on create_record. If not, the strip belongs on the engine insert path where its update-side twin already lives.

Either way readonly currently means something different on insert than on update, and the difference is not written down anywhere an application author would look.

Reproduction

Two duly_task inserts with an identical payload carrying a forged completed_at, one through protocol.createData and one through data.insert, both with no context. Pinned as a tripwire in objectstack-ai/duly — test/seed-history.test.ts, the insert-path strip is a BOUNDARY guard block — which is written to go red and be deleted when this is closed.

[huangyiirene]

Triage (R+89, triage seat, session session_019kDRpB7D2XzVzkaLp57T5D): pm:queue · priority:p2 · domain:engine · type Bug.

The card's question is answered by a standing meta-rule, not a new ruling. Maintainer-approved meta-criterion (2026-08-07): one operation, two implementations, inconsistent behaviour ⇒ the governed side wins by default; the other is re-bound, not aligned and not double-written. Here readonly on update is enforced in-engine (stripReadonlyFields, isSystem-gated) and on insert only at the protocol boundary (stripReadonlyForInsert in metadata-protocol) — so the governed side is the in-engine strip, and engine.insert is re-bound to it. Consequences the PR owes: the insert-path strip runs inside engine.insert for non-system callers with the same onFieldsDropped / warn behaviour as update, create_record's dead onFieldsDropped wiring starts receiving readonly drops, the boundary copy is deleted rather than kept as a second implementation, and assertReferencesResolve's doc sentence becomes true. Premise check binding on the dev: if #3425 (the card the reporter cites) recorded an explicit maintainer ruling that insert is a boundary-only concern, stop and report the fork — a ruling outranks the meta-rule. Absent that, proceed.

Clause-②: yes for the dispatch's tier decision — a published engine write path changes what it does with a caller-supplied readonly field (strip + report instead of write), which is an accept-behaviour change on a public path even though no wire schema moves. Landing files: packages/objectql/src/engine.ts (insert), the strip's home, metadata-protocol's createData/cloneData callers.

Family: #14259 (provenance, the same strip's update-side twin), #14088 (in flight). Hot file: packages/objectql/src/engine.ts — the engine seat answers fold-or-serial.

Size/model suggestion: M, claude-fable-5 per clause ②.

---

Generated by Claude Code