Three lint rule messages still tell authors that an undeclared field write has a driver-dependent outcome — "on a SQL driver the whole call fails with a driver-level error; on a schemaless driver (memory, MongoDB) the stray key is persisted". For the paths those three rules actually judge, that has not been true since #8682 / #8738.
Found while implementing #13657 (the post-hook half of the declared-field door). #13657 fixes the one message this claim was still true for — a hook body's own ctx.input write — and deliberately did not widen to these three, because they are a different, older staleness.
The three sites
| file |
line |
what it judges |
packages/lint/src/validate-hook-body-writes.ts |
~858 |
ctx.api.object('x').update({ ... }) inside a hook body |
packages/lint/src/validate-action-body-writes.ts |
~419 |
the same ctx.api write inside an action body |
packages/lint/src/validate-flow-node-writes.ts |
~298 |
a flow create_record / update_record node's fields map |
Why the claim looks stale
All three describe a fresh engine operation whose payload is CALLER-supplied, not a mutation of an in-flight ctx.input:
ctx.api is a ScopedContext over the triggering execution context (buildHookApi), so ctx.api.object('deal').update({ stagee: 'won' }) arrives at ObjectQL.update as an ordinary caller payload;- a flow node's
fields map is likewise handed to the engine as caller data.
The pre-hook declared-field door (#8682 insert, #8738 update) refuses a caller-named undeclared key from the object's field map, before the hooks and before any statement — so no driver is reached and there is no split to observe. That is already pinned, on both driver families, by the a CALLER-supplied undeclared key — the schema refuses, on both families block in packages/runtime/src/sandbox/undeclared-field-write-driver-split.integration.test.ts, which asserts INVALID_FIELD / 400 on SQL and on memory alike.
Why it matters
The rule file's own header states the reason this prose is governed: "a lint that misdescribes the failure it is warning about teaches the wrong debugging instinct". An author told to expect a driver-level column error, or a silently persisted key, will not connect the INVALID_FIELD / 400 they actually get to the typo that caused it — and on the schemaless side the message promises a persisted value that no longer exists.
Not verified here
I measured the hook-body ctx.input path end to end (real QuickJS sandbox, real engine, real driver-sql and driver-memory) because that was #13657's subject. I did not boot the ctx.api or flow-node paths — the claim above is derived from the call shape plus the existing caller-payload pin, so it wants a reproduction before the prose is rewritten.
Suggested scope
Re-measure the three paths, then rewrite the three messages to whatever they answer. Note that unprovisionedAnchorWriteConsequence() in the same file is a different case and appears still correct: an ADR-0015 external object's injected anchor IS declared in the registered schema, so it passes the door by construction and the remote database really is what refuses it.
Generated by Claude Code
Three lint rule messages still tell authors that an undeclared field write has a driver-dependent outcome — "on a SQL driver the whole call fails with a driver-level error; on a schemaless driver (memory, MongoDB) the stray key is persisted". For the paths those three rules actually judge, that has not been true since #8682 / #8738.
Found while implementing #13657 (the post-hook half of the declared-field door). #13657 fixes the one message this claim was still true for — a hook body's own
ctx.inputwrite — and deliberately did not widen to these three, because they are a different, older staleness.The three sites
packages/lint/src/validate-hook-body-writes.tsctx.api.object('x').update({ ... })inside a hook bodypackages/lint/src/validate-action-body-writes.tsctx.apiwrite inside an action bodypackages/lint/src/validate-flow-node-writes.tscreate_record/update_recordnode'sfieldsmapWhy the claim looks stale
All three describe a fresh engine operation whose payload is CALLER-supplied, not a mutation of an in-flight
ctx.input:ctx.apiis aScopedContextover the triggering execution context (buildHookApi), soctx.api.object('deal').update({ stagee: 'won' })arrives atObjectQL.updateas an ordinary caller payload;fieldsmap is likewise handed to the engine as caller data.The pre-hook declared-field door (#8682 insert, #8738 update) refuses a caller-named undeclared key from the object's field map, before the hooks and before any statement — so no driver is reached and there is no split to observe. That is already pinned, on both driver families, by the
a CALLER-supplied undeclared key — the schema refuses, on both familiesblock inpackages/runtime/src/sandbox/undeclared-field-write-driver-split.integration.test.ts, which assertsINVALID_FIELD/ 400 on SQL and on memory alike.Why it matters
The rule file's own header states the reason this prose is governed: "a lint that misdescribes the failure it is warning about teaches the wrong debugging instinct". An author told to expect a driver-level column error, or a silently persisted key, will not connect the
INVALID_FIELD/ 400 they actually get to the typo that caused it — and on the schemaless side the message promises a persisted value that no longer exists.Not verified here
I measured the hook-body
ctx.inputpath end to end (real QuickJS sandbox, real engine, realdriver-sqlanddriver-memory) because that was #13657's subject. I did not boot thectx.apior flow-node paths — the claim above is derived from the call shape plus the existing caller-payload pin, so it wants a reproduction before the prose is rewritten.Suggested scope
Re-measure the three paths, then rewrite the three messages to whatever they answer. Note that
unprovisionedAnchorWriteConsequence()in the same file is a different case and appears still correct: an ADR-0015externalobject's injected anchor IS declared in the registered schema, so it passes the door by construction and the remote database really is what refuses it.Generated by Claude Code