Schema: each expression field says which values and variables it accepts

jcoffey-dev commented

2026-09-28 17:37:06 +00:00

Owner

The registry knows, for every expression field, the constants it may evaluate to and the variables its conditions may read, and enforces both. The schema served to INBUXA Admin described every one as a bare x:Expression, so the console could offer nothing better than a free-text box.

tools/fork/expr-schema.py reads those contexts from the generated registry code and writes them onto each field's type:

{"type":"object","objectName":"x:Expression",
 "expression":{"constants":["relaxed","strict","disable"],
               "variables":["sender","sender_domain","rcpt","local_port",...]}}

All 124 expression fields are covered. The script fails if a context has no matching schema field.
Nothing else in the schema changes: it round-trips byte for byte apart from the new key.
CI runs expr-schema.py --check, so the schema can't drift from the registry. Re-run it after an upstream import (README updated).
The server reads the schema as untyped JSON (Explain, audit log), so the extra key is inert there. No Rust source changed.

First half of the expression simple mode in the console (settings-reorg spec); the admin PR follows.

Checked: name-check, notice-check, context-check, privacy-check, expr-schema --check and the fork unit tests pass.

The registry knows, for every expression field, the constants it may evaluate to and the variables its conditions may read, and enforces both. The schema served to INBUXA Admin described every one as a bare `x:Expression`, so the console could offer nothing better than a free-text box. `tools/fork/expr-schema.py` reads those contexts from the generated registry code and writes them onto each field's type: ```json {"type":"object","objectName":"x:Expression", "expression":{"constants":["relaxed","strict","disable"], "variables":["sender","sender_domain","rcpt","local_port",...]}} ``` - All 124 expression fields are covered. The script fails if a context has no matching schema field. - Nothing else in the schema changes: it round-trips byte for byte apart from the new key. - CI runs `expr-schema.py --check`, so the schema can't drift from the registry. Re-run it after an upstream import (README updated). - The server reads the schema as untyped JSON (Explain, audit log), so the extra key is inert there. No Rust source changed. First half of the expression simple mode in the console (settings-reorg spec); the admin PR follows. Checked: name-check, notice-check, context-check, privacy-check, expr-schema --check and the fork unit tests pass.

jcoffey-dev added 1 commit 2026-09-28 19:32:40 +00:00

Schema: each expression field says which values and variables it accepts

ci / fork-checks (pull_request) Successful in 52s

Details

ci / build (pull_request) Successful in 5m24s

Details

e61a475859

The registry knows, for every expression field, the constants it may
evaluate to and the variables its conditions may read, and enforces both.
The schema served to INBUXA Admin described every one as a bare
x:Expression, so the console could offer nothing better than free text.

tools/fork/expr-schema.py reads those contexts from the generated registry
code and writes them onto each field's type as
expression: {constants, variables}. All 124 expression fields are covered.
CI runs it with --check so the schema can't drift from the registry.

jcoffey-dev force-pushed feature/expression-schema from 820ef5df2c to e61a475859

2026-09-28 19:32:40 +00:00

Compare

jcoffey-dev merged commit 32b22d0828 into main

2026-09-28 21:51:35 +00:00

jcoffey-dev deleted branch feature/expression-schema

2026-09-28 21:51:35 +00:00

jcoffey-dev referenced this pull request

2026-09-28 23:57:55 +00:00

Release 2026.9.28.5 #98

Schema: each expression field says which values and variables it accepts #91