Symptom
A manifest that uses a schema feature newer than the gate's vendored copy is reported as
invalid, with a message naming the feature ("flow" is not one of [...]). Nothing in that output
says the gate is out of date, so the reader goes looking for a bug in their manifest.
Hit twice today, blocking dossiq#1402 and openregister#2937. Fixed for now by #602, which only
refreshes the copy.
Cause
hydra-gates/scripts/schemas/app-manifest-v2.schema.json is a vendored copy of the schema that
@conduction/nextcloud-vue publishes. The gate loads it and validates. The schema carries a
version field — the gate never reads it.
So the gate cannot distinguish:
| Reality |
What the gate says |
| The manifest is genuinely wrong |
"flow" is not one of [...] |
| The manifest is newer than the gate |
"flow" is not one of [...] |
Identical output, opposite fixes, different repos. That is the whole defect — not the staleness
itself, which is inevitable in a vendored copy, but that staleness is indistinguishable from
authorship error.
Proposed fix
Have the gate compare versions and say which side is behind:
- Read
version from the vendored schema.
- Read the version the app targets — its installed
node_modules/@conduction/nextcloud-vue
schema, or a $schemaVersion the manifest declares.
- If the app targets a newer schema, fail with that fact:
manifest targets 2.26.0, gate ships 2.25.0 — refresh ConductionNL/.github.
That message routes to the right repo. The current one routes to the wrong one.
Notes
- This is the fourth copy of this schema found drifting this week; the others are in
nextcloud-vue, the app repos' vendored fallback, and dossiq's own validator.
- Validating against
node_modules directly is tempting but not obviously right: the gate would
then validate against whatever the app pinned, which is not a fleet-wide standard. The version
comparison is the part that is unambiguously correct — do that first.
- A validator and an executor each owning a copy of one grammar drift silently. Same shape as the
24 filters that were accepted at save and matched nothing at run.
Symptom
A manifest that uses a schema feature newer than the gate's vendored copy is reported as
invalid, with a message naming the feature (
"flow" is not one of [...]). Nothing in that outputsays the gate is out of date, so the reader goes looking for a bug in their manifest.
Hit twice today, blocking
dossiq#1402andopenregister#2937. Fixed for now by #602, which onlyrefreshes the copy.
Cause
hydra-gates/scripts/schemas/app-manifest-v2.schema.jsonis a vendored copy of the schema that@conduction/nextcloud-vuepublishes. The gate loads it and validates. The schema carries aversionfield — the gate never reads it.So the gate cannot distinguish:
"flow" is not one of [...]"flow" is not one of [...]Identical output, opposite fixes, different repos. That is the whole defect — not the staleness
itself, which is inevitable in a vendored copy, but that staleness is indistinguishable from
authorship error.
Proposed fix
Have the gate compare versions and say which side is behind:
versionfrom the vendored schema.node_modules/@conduction/nextcloud-vueschema, or a
$schemaVersionthe manifest declares.manifest targets 2.26.0, gate ships 2.25.0 — refresh ConductionNL/.github.That message routes to the right repo. The current one routes to the wrong one.
Notes
nextcloud-vue, the app repos' vendored fallback, anddossiq's own validator.node_modulesdirectly is tempting but not obviously right: the gate wouldthen validate against whatever the app pinned, which is not a fleet-wide standard. The version
comparison is the part that is unambiguously correct — do that first.
24 filters that were accepted at save and matched nothing at run.