Repository navigation
tracking: droppedFields write-observability is asymmetric across the Virtual Data Engine RPC boundary (update best-effort, create surfaces) #3476
Description
Activity
Closing after verification (2026-07-25): the boundary this issue guards does not exist at runtime.
- `DataEngineRequestSchema` ("Virtual ObjectQL", `packages/spec/src/data/data-engine.zod.ts` §9) defines request schemas only — there is no response schema at all.
- Zero runtime consumers repo-wide (cloud included): no HTTP endpoint accepts these requests, and no remote proxy implements `IDataEngine`. The only implementation is the in-process ObjectQL engine (`packages/objectql/src/engine.ts`).
- The Virtual Data Engine therefore sits in the same "declared, no runtime consumer" family as GraphQL (Tracking: Studio-authored metadata that's declared but never wired at runtime (the 'silently does nothing' family) #2605 / Audit: several event/subscription/connector enums are schema-only (declared, no runtime consumer) #3197). The update-side `droppedFields` gap is unreachable in every deployment topology that exists today.
Design constraint to carry forward if/when a VDE is actually implemented — treat this issue as an acceptance criterion for that work:
- The write-path RPC response contract MUST carry `droppedFields` (option 1 here), so the remote engine reports its own strips.
- Option 2 (recomputing update strips at the protocol layer via a pre/post diff) should not be built even then: it costs a pre-read per update and duplicates `readonlyWhen` predicate evaluation outside the engine — a permanent two-implementation drift tax.
- Option 3 (document the limitation) is already done: the schema comment on `DroppedFieldsEventSchema` states the listener cannot cross the RPC boundary.
Nothing to build until the VDE has a runtime.
Split out from #3455 / #3468 (design note #3413).
The asymmetry
droppedFields(write-observability for LEGALLY-stripped fields —readonly#2948 /readonlyWhen#3042 / #3043 create ingress) reaches the caller via two different mechanisms with different reach:readonlystrip is computed at the protocol layer (stripReadonlyForInsert+ a before/after payload diff inmetadata-protocol), so it surfaces even when the data engine is remote (Virtual Data Engine / RPC). Applies tocreateData,createManyData,insertManyData, and batchcreaterows.readonly/readonlyWhenstrips happen inside the engine, reported via the in-processonFieldsDroppedlistener (feat(automation): update_record/create_record 步骤对被静默剥离的写入字段挂 warning(#3407) #3413). That callback does not cross the RPC boundary, so for a remote engine the update-sidedroppedFieldsis best-effort / absent. Applies toupdateData,updateManyData, and batchupdate/upsertrows.#3468 extended both channels to the bulk paths, so bulk now inherits the exact same asymmetry the single-write path already had (acknowledged in #3413).
Why it matters
A cross-process deployment (Virtual Data Engine) gets reliable drop reporting on creates but silent success on updates — the very silent-success class #3407 set out to remove, re-appearing only at the process seam.
Options to consider
onFieldsDroppedevents across the RPC envelope (add adroppedFieldsfield to the engine's remote write-response contract) so the remote engine reports its own strips.No runtime bug today (single-process/ObjectQL deployments are fully covered); this tracks closing the remote gap.
Refs: #3455, #3468, #3413, #3407.