fix(contract): restate MAX_PRIORITY_ELIGIBILITY_WINDOW_MINUTES so the generated schemas compile - #9936
Conversation
… generated schemas compile main is currently failing `contract:api-schemas:check` for every PR. #9738 added `.max(MAX_PRIORITY_ELIGIBILITY_WINDOW_MINUTES)` to the settings schema in src/openapi/schemas.ts. gen-contract-api-schemas.ts copies that schema verbatim into @loopover/contract, which cannot import the Worker's src/ -- so a referenced constant has to be restated in the contract's own limits.ts. That step was missed, leaving both paths broken: regenerating emits a file referencing a name it never imports (TS2304, contract build fails), and NOT regenerating leaves the drift check red. The generator's doc calls this "the loud failure this wants", and it worked -- it just needs the constant it was asking for. Also pins the three restated Worker bounds against their originals. limits.ts says they are "pinned against their originals like every other entry here", but PREFLIGHT_LIMITS was the only group with a meta-test doing that; the single constants were restated on trust. Nothing at compile time relates the two copies (that is the whole reason the contract is a zod-only leaf), so a one-sided edit would surface as a client-side validation error rather than a build failure. The compile-time failure only catches a MISSING constant, never a drifted VALUE.
|
Warning ⏸️ LoopOver review result - manual review recommendedReview updated: 2026-07-30 17:55:41 UTC
Review summary Nits — 3 non-blocking
Concerns raised — review before merging
📋 Copy for AI agents — paste into your coding agentDecision drivers
Context & advisory signals — never blocks the verdict
Review context
Contributor next steps
Signal definitions
🧪 Chat with LoopOverAsk LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.
Full command reference: https://loopover.ai/docs/loopover-commands 🧪 Experimental — new and may change. Decision record
🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed 💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.
|
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #9936 +/- ##
==========================================
- Coverage 91.88% 91.01% -0.88%
==========================================
Files 923 923
Lines 113407 113408 +1
Branches 27332 27332
==========================================
- Hits 104205 103214 -991
- Misses 7915 9104 +1189
+ Partials 1287 1090 -197
Flags with carried forward coverage won't be shown. Click here to find out more.
|
mainis currently failingcontract:api-schemas:check, which blocks every PR.What happened
#9738 added
.max(MAX_PRIORITY_ELIGIBILITY_WINDOW_MINUTES)to the settings schema insrc/openapi/schemas.ts.gen-contract-api-schemas.tscopies that schema verbatim into@loopover/contract, which cannot import the Worker'ssrc/— it is a zod-only leaf, and that property is what lets every other surface depend on it. Referenced constants therefore have to be restated in the contract's ownlimits.ts. That step was missed, leaving both paths broken:TS2304: Cannot find name 'MAX_PRIORITY_ELIGIBILITY_WINDOW_MINUTES', contract build fails.contract:api-schemas:checkstays red.Verified against a pristine
origin/mainworktree, so this is not local drift.The generator's own doc comment calls this "the loud failure this wants" — it worked exactly as designed. It just needs the constant it was asking for.
Also: actually pin the restated bounds
limits.tssays these entries are "pinned against their originals like every other entry here", butPREFLIGHT_LIMITSwas the only group with a meta-test doing the pinning — the three single constants were restated on trust, which is the same as not being pinned.That gap is one-sided and quiet: nothing at compile time relates the two copies, so raising a bound on the Worker side alone leaves the published schema rejecting input the server would now accept (and vice versa), surfacing as a confusing client-side validation error rather than a build failure. Note the compile-time failure this PR fixes only ever catches a missing constant — never a drifted value.
test/unit/contract-limits-pinned.test.tscloses that for all three, one case each so a failure names the specific bound and the file to reconcile it with.