Summary
packages/spec/src/data/validation.zod.ts defines 9 validation rule types, but the write-path validator packages/objectql/src/validation/rule-validator.ts only enforces 3 of them. The other 6 are accepted by the schema (so authors can declare them) but silently do nothing on insert/update — the same "advertise a capability we don't deliver" problem we just fixed for the ChartType taxonomy.
Enforced (3)
state_machine — transition guard (✅ verified: invalid transition → HTTP 400 invalid_transition)
script — CEL predicate
cross_field — CEL predicate across fields
See rule-validator.ts ~L152-157:
if (rule.type === 'state_machine') { ... }
else if (rule.type === 'script' || rule.type === 'cross_field') { ... }
// Other rule types are not enforced on the write path (yet).
Declared but NOT enforced (6)
unique (the validation-rule variant; note field-level unique: true is a separate, working mechanism via the driver index)
format
json_schema
async
custom
conditional
Why it matters
- A schema author can add, e.g., a
format or json_schema validation and reasonably expect it to run; it won't. Silent no-op is worse than an explicit "unsupported".
- The showcase (
@objectstack/example-showcase) deliberately only demonstrates the 3 enforced types, because demonstrating the others would be misleading (declared ≠ validated).
Options (pick a direction)
- Implement enforcement for the missing types on the write path (at least the synchronous ones:
unique, format, json_schema, conditional; async/custom need a handler-execution model).
- Trim the spec to the enforced set (like the ChartType taxonomy trim), and reintroduce types as they get real enforcement.
- Hybrid: keep the schema but make the validator
console.warn once per unsupported rule type at load so misconfiguration is visible.
Acceptance
- Every
ValidationRuleSchema variant either runs on the write path or is removed from the schema (no silent no-ops).
- Showcase gains a demonstrated + verified example for each newly-enforced type.
Found while completing the state_machine showcase coverage (framework #1474).
Summary
packages/spec/src/data/validation.zod.tsdefines 9 validation rule types, but the write-path validatorpackages/objectql/src/validation/rule-validator.tsonly enforces 3 of them. The other 6 are accepted by the schema (so authors can declare them) but silently do nothing on insert/update — the same "advertise a capability we don't deliver" problem we just fixed for theChartTypetaxonomy.Enforced (3)
state_machine— transition guard (✅ verified: invalid transition → HTTP 400invalid_transition)script— CEL predicatecross_field— CEL predicate across fieldsSee
rule-validator.ts~L152-157:Declared but NOT enforced (6)
unique(the validation-rule variant; note field-levelunique: trueis a separate, working mechanism via the driver index)formatjson_schemaasynccustomconditionalWhy it matters
formatorjson_schemavalidation and reasonably expect it to run; it won't. Silent no-op is worse than an explicit "unsupported".@objectstack/example-showcase) deliberately only demonstrates the 3 enforced types, because demonstrating the others would be misleading (declared ≠ validated).Options (pick a direction)
unique,format,json_schema,conditional;async/customneed a handler-execution model).console.warnonce per unsupported rule type at load so misconfiguration is visible.Acceptance
ValidationRuleSchemavariant either runs on the write path or is removed from the schema (no silent no-ops).Found while completing the state_machine showcase coverage (framework #1474).