docs(openapi): pin Customer schema field lengths to match the validators#270
Merged
Merged
Conversation
The OpenAPI \`Customer\` component declared every string field as a bare \`type: 'string'\` with no length constraint. The actual zod validators in customer.schema.js have concrete max lengths (and a fixed \`.length(2)\` on custState per #265). SDK generators (openapi-typescript et al.) consume the OpenAPI spec, so without these constraints client-side types miss the real bounds and a SDK-driven 400 surprises the caller. What changed: - custState: type 'string' with min/maxLength: 2 (per #265 fix) - custZip / custPhone / custEmail: explicit maxLength matching the zod schema (32 / 64 / 255) - custCompanyName / FName / LName / Address1/2 / City: maxLength 255 each No behavior change — runtime still validates via the same zod schema; this just brings the published contract into agreement with reality. 760 tests still pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CryptoJones
added a commit
that referenced
this pull request
May 19, 2026
…rs (#272) Mirror of the customer fix in #270. The OpenAPI Company component schema had compState with maxLength: 2 already, but the other fields were unbounded — even though company.schema.js validates them with concrete .min/.max constraints (and the DB columns underneath cap compPhone at varchar(32)). Aligned every string field with the runtime contract: - compName: minLength: 1, maxLength: 255 (per zod min(1).max(255)) - compAddress1/2 / compCity / compEmail: maxLength: 255 - compState: minLength: 2, maxLength: 2 - compZip / compPhone: maxLength: 32 SDK generators (openapi-typescript et al.) now carry the bounds into client types. No behavior change. 760 tests still pass. Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CryptoJones
added a commit
that referenced
this pull request
May 19, 2026
#276) Same pattern as the customer fix (#270) and company fix (#272). \`worker.schema.js\` validates workerFName / workerLName / workerTitle each as \`z.string().min(1).max(255)\`. The OpenAPI Worker component had them as bare \`type: 'string'\` with no bounds; SDK generators (openapi-typescript et al.) couldn't surface the constraint, so clients generated from the spec missed the minimum-1-char floor and the 255-char ceiling. Set \`minLength: 1, maxLength: 255\` on each name field. No behavior change. 760 tests still pass. Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CryptoJones
added a commit
that referenced
this pull request
May 19, 2026
…ts (#290) Extends the field-length / numeric-bound pinning sweep started in #270 (Customer), #272 (Company), and #276 (Worker) to the two remaining single-table entity components. BillingType: - btName: minLength: 1, maxLength: 255 (per zod min(1).max(255)) - btHourlyRate: minimum: 0 (per zod nonnegative()) InventoryItem: - invitDescription: minLength: 1, maxLength: 1000 (per zod min(1).max(1000)) \`finite\` is implicit in OpenAPI's number type per the spec (no NaN / Infinity in JSON), so no extra annotation is needed there. SDK generators now carry the bounds into client-side types for these two entities, matching the rest of the spec. No behavior change. 760 tests still pass. Co-authored-by: Aaron K. Clark <akclark@thenetwerk.net> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This was referenced May 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The OpenAPI
Customercomponent schema declared every string field as a baretype: 'string'with no length constraint. The actual zod validators incustomer.schema.jshave concrete max lengths — and as of #265 a fixed.length(2)oncustState.SDK generators (openapi-typescript et al.) consume the OpenAPI spec, so without these constraints client-side types miss the real bounds and a SDK-driven 400 surprises the caller.
What changed
custState: now{ minLength: 2, maxLength: 2 }to match the fix(schema): cap custState at 2 chars to match DB column #265 zod fix.custZip,custPhone,custEmail: explicitmaxLengthmatching the zod schema (32 / 64 / 255).custCompanyName,FName,LName,Address1,Address2,City:maxLength: 255each.Test plan
npm run lint && npm test— 760 passingProudly Made in Nebraska. Go Big Red! 🌽 https://xkcd.com/2347/