Undeclared fields still reach the driver: beforeInsert hooks run and an auto-number is consumed before the request is refused, and the whole INSERT with its values is logged at ERROR (17.0.0 GA)

[hotlong]

Part of objectstack-ai/hotcrm#689 (never mirrored until now). Measured on @objectstack/* 17.0.0 GA during HotCRM's GA close-out sweep (hotcrm#1150 / #1152), using that card's own reproduction verbatim.

The client-facing behaviour is correct and unchanged — a clean 400 INVALID_FIELD. This is about what happens behind it. Two halves, which have different states.

Half A — validation ordering: REPRODUCES

An unknown field is still rejected by the driver, not by schema validation, and everything upstream of the statement has already run.

POST /api/v1/data/crm_account {"name":"P689 probe","zzz_nonexistent_field":"x"}
-- 400 {"error":"Unknown field 'zzz_nonexistent_field' on object 'crm_account'","code":"INVALID_FIELD"}

server log:

ERROR Insert operation failed {"object":"crm_account","error":{"message":
"insert into `crm_account` (`account_number`, `created_at`, `created_by`, `id`, `is_active`,
`name`, `name_normalized`, `organization_id`, `owner_id`, `territory`, `tier`, `type`,
`updated_at`, `updated_by`, `zzz_nonexistent_field`) values ('ACC-000011',
'2026-08-14T13:08:49.769Z', 'DWci...', 'q-UpNH4tqX3n3wKP', true, 'P689 probe ...',
'p689 probe ...', 'org_mssy5q4o0pc5iqui', ...) returning *
 - table crm_account has no column named zzz_nonexistent_field"

An id, an auto-number, a normalized name, owner/creator resolution and three column defaults were all produced for a request that was about to be refused.

Hooks run too. crm_forecast uses nameField: 'display_title', so name is undeclared there:

insert into `crm_forecast` (..., `period`, `period_end`, `period_label`, `period_start`, ...)
values (..., 'quarter', '2026-09-30', 'Q3 2026', '2026-07-01', ...)
 - table crm_forecast has no column named name

period_label = 'Q3 2026' was never sent by the caller; it is derived by the app's beforeInsert hook. The hook executed on a request that was then rejected.

Independent of the log, the auto-number sequence shows the same thing — this observable does not depend on log contents at all:

valid create before the bad request : ACC-000013
the bad request : 400 INVALID_FIELD
valid create after the bad request : ACC-000015
-- gap across the rejected request : 1 (the refused request consumed ACC-000014)

Half B — value logging: PARTLY fixed, the exposure survives

sub-claim on hotcrm#689	GA state
the entry appears as [REST] Unhandled error, a false unhandled signal	FIXED — zero [REST] Unhandled error lines carry a SqliteError or no column named in a full run; the entry is now a single handled ERROR Insert operation failed
the full INSERT with every value is written at ERROR level	REPRODUCES
each entry duplicates the whole statement twice (message + stack)	REPRODUCES — the stack field opens SqliteError: insert into ... with the statement again

Confirmed with planted canaries: a request carrying description: 'DESCRIPTION-VALUE-CANARY' and a misspelled zzz_secret_field: 'SENSITIVE-CANARY-9f3a2b' put both literals into the log, alongside the organization id and the acting user id. A single mistyped field name in a client request is still enough to write an entire row's values to disk at ERROR level.

Suggested direction

Reject unknown fields against the object schema before hooks and before statement construction; and when a driver-level error does reach the logger, log the failing column and the object rather than the bound statement.

Evidence: hotcrm#1152 probe 50-689.mjs; readings posted on hotcrm#689.

---

Generated by Claude Code

[hotlong]

Triage: lands in packages/objectql/src/engine.ts (the Insert operation failed logger and the insert ordering — verified on origin/main @ 1eb28a1) ⇒ domain:engine-core. Type Bug, queued. security label applied for half B.

Rationale: routed by landing package. Both halves are in the engine's insert path, so this is one card, not two lanes.

Not escalated. Half A restores declared ordering (an undeclared field is refused by the schema, not by the driver); half B narrows what is written to disk. Neither expands the accept set or the public face.

Half B is the half with a deadline-free but real exposure, and it should not be traded away for half A being tidier: a single mistyped field name in a client request writes an entire row's values — including the planted SENSITIVE-CANARY — to disk at ERROR level, twice (message + stack). If only one half can land cleanly, land B first; it is smaller and it is the one with a security consequence.

The card's strongest evidence is the log-independent one: the auto-number gap across the rejected request (ACC-000013 → 400 → ACC-000015). Keep that as the regression pin's observable — a pin that greps log contents will rot the moment the logger is changed by half B, which is the same PR.

⛔ Do not "fix" half B by lowering the log level or dropping the entry. The failing column and object must still be logged, or the next driver-level fault becomes undebuggable — that is the tolerant-fallback direction, not the loud one.

Size/model suggestion: M, opus.

---

Generated by Claude Code

[hotlong]

Claim: PM loop round 1
Session: session_01XeQRiAa7vYRVX5Fog7Zby8
Branch: claude/issue-8682-undeclared-field-preflight
Worktree: objectstack-issue-8682
Domain: domain:engine-core
File surface: packages/objectql/src/engine.ts — the insert path and the Insert operation failed logger (verified on origin/main at engine.ts:8381), plus its co-located tests (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: no open PR touches packages/objectql (6 open PRs read). Latest main touch to engine.ts is 478f1fd (#8616, empty-string writes to secret/password fields) — a different region, and not same-day churn against this card's seam. Batch sibling #8690 lands in packages/core; disjoint by package.

Dispatching under the maintainer's direct-dispatch instruction to this PM session (2026-08-14, verbatim, untranslated): 「metadata ＋ engine-core ＋ drivers 优先处理bug」. Lane seat #6019 is vacant.

Carrying triage's ruling from 5294749443 intact, including its two ⛔ clauses: land half B first if only one half lands cleanly, ⛔ do not "fix" half B by lowering the log level or dropping the entry (the failing column and object must still be logged), and pin the regression on the log-independent observable — the auto-number gap across the rejected request — because a pin that greps log contents rots the moment half B changes the logger in the same PR.

---

Generated by Claude Code