v3 policy: create() with a Json value containing a top-level "kind" key fails with "Invariant failed: expecting a ValueNode"

[twobyte]

Description

A create() whose Json field value contains a top-level kind key fails through the policy plugin with:

Invariant failed: expecting a ValueNode

The same payload succeeds via update(), and via create() when the kind key is renamed or omitted — so the JSON value itself is fine; only the create path through the policy plugin rejects it.

This looks like the policy plugin's pre-create check (unwrapCreateValueRow) walking each column value looking for embedded Kysely query/operation nodes, which it recognises by their kind discriminator property. A plain JSON object that happens to have its own kind key is mistaken for a node and fails the item.kind === "ValueNode" invariant.

kind is a fairly natural domain field name (ours tags imagery/artwork payloads), so this is easy to hit and confusing to diagnose — the error surfaces as a policy-layer invariant with no hint that a payload key is the trigger.

Reproduction

Schema:

model Item {
    id      Int  @id @default(autoincrement())
    payload Json

    @@allow('all', true)
}

Code:

import { ZenStackClient } from "@zenstackhq/orm";
import { PolicyPlugin } from "@zenstackhq/plugin-policy";
import { schema } from "./zenstack/schema";

const db = new ZenStackClient(schema, { dialect }).$use(new PolicyPlugin());

// ❌ throws: Invariant failed: expecting a ValueNode
await db.item.create({ data: { payload: { kind: "artwork" } } });

// ✅ works — same shape, key renamed
await db.item.create({ data: { payload: { type: "artwork" } } });

// ✅ works — same value via update
const item = await db.item.create({ data: { payload: {} } });
await db.item.update({ where: { id: item.id }, data: { payload: { kind: "artwork" } } });

Expected behaviour

A JSON column value is treated as opaque data regardless of its keys; create() and update() accept the same payloads.

Actual behaviour

create() through the policy plugin throws Invariant failed: expecting a ValueNode whenever the JSON value has a top-level kind key. update() accepts the identical value.

Workaround

Create without the kind key, then patch it in with an update() in the same transaction — the stored payload ends up identical. We pin the quirk (and the workaround) with an integration test so we can drop the dance once fixed.

Environment

• @zenstackhq/orm 3.9.0, @zenstackhq/plugin-policy 3.9.0, @zenstackhq/cli 3.9.0
• Postgres dialect (@zenstackhq/orm/dialects/postgres + pg)
• Also reproduced on 3.7.2

[sanny-io]

The reproduction provided does not work unless I use a non-constant condition for the policy.

model Item {
    id      Int  @id @default(autoincrement())
    payload Json

    @@allow('all', auth() == null)
}

Interestingly, the error does not occur when using strongly-typed JSON. I've narrowed it down to this different behavior.

zenstack/packages/orm/src/client/crud/dialects/postgresql.ts

Lines 188 to 196 in 797b5bc

	if (isTypeDef(this.schema, type)) {
	// type-def fields (regardless array or scalar) are stored as scalar `Json` and
	// their input values need to be stringified if not already (i.e., provided in
	// default values)
	if (typeof value !== 'string') {
	return JSON.stringify(value);
	} else {
	return value;
	}

zenstack/packages/orm/src/client/crud/dialects/postgresql.ts

Lines 223 to 234 in 797b5bc

	case 'Json':
	if (
	value === null ||
	typeof value === 'string' ||
	typeof value === 'number' ||
	typeof value === 'boolean'
	) {
	// postgres requires simple JSON values to be stringified
	return JSON.stringify(value);
	} else {
	return value;
	}

It's not clear to me why the handling between them needs to be different.