Fix: include acceptTerms in workspace create body to match generated client - #12
Open
polylane[bot] wants to merge 1 commit into
Open
Fix: include acceptTerms in workspace create body to match generated client#12polylane[bot] wants to merge 1 commit into
polylane[bot] wants to merge 1 commit into
Conversation
…client Co-authored-by: polylane[bot] <277585245+polylane[bot]@users.noreply.github.com>
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
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.
🟡 Fixes: CI failing: CI on coreplanelabs/cli@main
active for 5m
fix_fc511a…CI typecheck on main was failing because the workspace create command was sending a request body missing a required
acceptTermsfield that the generated API client expects. PR #10 removedacceptTermsfrom the body on the assumption the server rejects unknown fields, but the live OpenAPI spec still declares it as required, and the codegen step in CI regenerates a client with that requirement. This change restoresacceptTerms: trueto the request body so the typecheck passes and the server records the terms acceptance, consistent with the existing user-facing notice.What changed
src/commands/workspace/create.ts: re-addedacceptTerms: trueto theCreateWorkspaceBodyliteral on line 37, matching the generated client's required{ name; description?; slug?; link?; acceptTerms: true }shape.Validation
npm run typecheck— codegen +tsc --noEmitpasses (exit 0), resolving TS2741 on line 37 ofsrc/commands/workspace/create.ts.Root cause, safety reasoning, and scoping notes
Root cause
Without this fix,
npm run typecheckin CI (and locally afternpm run codegen) fails atsrc/commands/workspace/create.ts:37with TS2741, blocking all PRs from going green. The spec the server publishes requiresacceptTerms; the CLI already prints a terms-acceptance notice on stderr before the call, so populating the field aligns the code with both the contract and the UX.Why it's safe
Additive-only: re-adds a field the generated client already requires. No schema, interface, or behavior change beyond populating a previously-required field the server expects and records.
Out of scope / follow-ups
1 file changed (+1/-1)
src/commands/workspace/create.ts: modified, +1/-1Generated by Polylane.