(MOT-4516) fix(opengantry): type response schemas so the release can publish - #853
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
Next review available in: 35 minutes Limit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
skill-check — worker0 verified, 62 skipped (no docs/).
Four for four. Nicely done. |
…publish
opengantry has never been released. It routes correctly through the
generic pipeline (deploy: bundle + language: javascript), but its first
registry publish would hard-fail: _publish-registry.yml boots the built
bundle and runs collect_worker_interface.py --assert-typed-schemas, which
rejects any request/response schema lacking a schema-defining keyword.
Two responses were z.unknown(), which z.toJSONSchema compiles to {}:
gantry::middleware -> z.record(z.string(), z.unknown())
gantry::on-trigger-type-registration -> z.object({}).strict()
middleware is a pass-through gate, so on allow the response is whatever
the forwarded call returned; typed as an open object, the shape openwiki
already uses for open payloads. Widen to anyOf if a governed function
ever returns a bare scalar or array. onTriggerTypeRegistration throws
GantryDenied unconditionally and has no success shape at all.
That assertion only runs after the tag, the GitHub Release, and the
tarball upload, so the failure would land mid-operation and need a
Release Control recovery. tests/formats.test.mjs pins the invariant
locally instead, mirroring SCHEMA_DEFINING_KEYS from the CI script. No
workflow changes: ci.yml's node job already runs npm test for changed
workers in the node bucket.
gantry::verdict still publishes without an invocation schema and renders
as "unknown" in the registry. That is a warning rather than a blocker,
and is not fixable here: RegisterTriggerTypeInput in iii-sdk 0.22.1 is
{id, description} only, with no JS equivalent of Rust's
.trigger_request_format::<T>().
b48a069 to
c6c4790
Compare
1 participant
opengantrylanded in #814 but has never been released — it is the only bundle worker with noopengantry/v*tag. This makes its first release possible.There is no release pipeline to add. Release here is one generic, manifest-driven machine:
release.ymlparses the<worker>/vX.Y.Ztag, readsiii.worker.yaml, and fans out ondeploy:.ci.yml'sdiscoverjob enumerates workers off the filesystem and buckets them onlanguage:. No workflow names a worker, andgrep -rn opengantry .github/returns nothing — correctly so. opengantry already declareslanguage: javascript+deploy: bundleand has thebuild:bundlescript_bundle.ymlneeds, so it is routed fine.It just isn't publishable.
The blocker
_publish-registry.ymldownloads the built tarball, boots the worker against a real engine, and runscollect_worker_interface.py --assert-non-empty --assert-typed-schemas. That rejects any request/response schema lacking a schema-defining keyword (SCHEMA_DEFINING_KEYSin.github/scripts/collect_worker_interface.py:22).Two responses were
z.unknown(), whichz.toJSONSchemacompiles to{}:gantry::middlewarez.unknown()z.record(z.string(), z.unknown())gantry::on-trigger-type-registrationz.unknown()z.object({}).strict()middlewareis a pass-through gate — on allow the response is whatever the forwarded call returned (middleware.js:86), so it is typed as an open object, the shapeopenwiki/src/lib/configuration.mjs:89already uses for open payloads. Widen toanyOfif a governed function ever returns a bare scalar or array; it is registry documentation, not a runtime validator.onTriggerTypeRegistrationthrowsGantryDeniedunconditionally (registration-hooks.js:36) and has no success shape at all.That assertion only runs after the tag, the GitHub Release, and the tarball upload — so this would have failed mid-operation and needed a Release Control recovery.
The guard
tests/formats.test.mjsasserts everyFUNCTION_FORMATSentry compiles to a typed schema, mirroring the CI keyword set with a comment pointing back at the script. No workflow changes needed:ci.yml'snodejob already runsnpm testfor changed workers in thenodebucket.Verified it discriminates — reverting
MiddlewareResponseSchematoz.unknown()fails withgantry::middleware.response_schema.Verification
From
opengantry/, using the release path's own commands:pnpm install --frozen-lockfile --ignore-workspacepnpm test— 42/42 passpnpm lint— biome 2.4.10 cleanpnpm run build:bundle— 1.2mbpnpm run verify:sandbox— boots and registersAll ten schemas now carry
type.Not in scope
gantry::verdictpublishes with no invocation schema and renders as "unknown" in the registry. Warning, not a blocker (_untyped_trigger_nameswarns;_typed_schema_violationsfails), and not fixable here:RegisterTriggerTypeInputin iii-sdk 0.22.1 is{id, description}only, with no JS equivalent of Rust's.trigger_request_format::<T>().ci.yml'snodejob installs withnpm install(opengantry ships only apnpm-lock.yaml) while_bundle.ymlandrelease_train.pyusepnpm install --frozen-lockfile --ignore-workspace, so PR CI resolves deps unpinned. Pre-existing, affects all five JS workers, deliberately left alone.create-tag.ymlowns that.After merge
Cutting
opengantry/v0.1.0is a Release Control dispatch (create-tag.yml, thenrelease.yml). It requiresopengantryin the Release Control typed release policy first (docs/sops/new-worker.md§6) — that is outside this repo and cannot be done from here.Fixes MOT-4516