Skip to content

Fix OpenAPI 3.0 sign schema and setup payload error reporting#3

Merged
Dan-Cleary merged 1 commit into
mainfrom
fix/public-openapi-cli-validation
Mar 3, 2026
Merged

Fix OpenAPI 3.0 sign schema and setup payload error reporting#3
Dan-Cleary merged 1 commit into
mainfrom
fix/public-openapi-cli-validation

Conversation

@Dan-Cleary
Copy link
Copy Markdown
Owner

@Dan-Cleary Dan-Cleary commented Mar 3, 2026

Summary: update OpenAPI sign schema for OpenAPI 3.0 compatibility and improve CLI setup invalid payload diagnostics for POST /v1/workspaces. Test plan: npm run build --prefix packages/cli.

Made with Cursor

Summary by CodeRabbit

  • Bug Fixes
    • Enhanced error messaging during workspace setup to provide clearer feedback when API responses contain invalid data, improving the user experience during initial configuration.
    • Refined asset signing endpoint schema validation to ensure consistency and accuracy of API specification requirements.

Replace unsupported OpenAPI const usage with 3.0-compatible enums and make CLI setup report invalid workspace creation payloads explicitly instead of classifying them as network failures.

Made-with: Cursor
@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Mar 3, 2026

📝 Walkthrough

Walkthrough

This pull request refines the OpenAPI schema for the asset signing endpoint's permanent property by replacing constant declarations with enum constraints, and enhances CLI setup error handling by introducing a dedicated InvalidPayloadError class for invalid webhook payload responses.

Changes

Cohort / File(s) Summary
OpenAPI Schema
openapi/agentstorage.v1.yaml
Updated permanent property constraints in /v1/assets/{assetId}/sign requestBody: replaced const: true with enum: [true], and changed second variant from enum: [false, null] to type: boolean, enum: [false], nullable: true.
CLI Error Handling
packages/cli/src/commands/setup.ts
Introduced InvalidPayloadError class and updated POST /v1/workspaces error handling to throw this new error type instead of generic Error when response payload is invalid; extended error catch logic to handle the new error type.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 A hop through schemas, a bound through errors,
The permanent state finds new bearers,
InvalidPayload speaks its truth,
Refining logic with careful proof—
CodeRabbit hops onward, ever truth!

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately summarizes the two main changes: fixing the OpenAPI 3.0 sign schema and improving setup payload error reporting, directly matching the file-level changes.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
  • 📝 Generate docstrings (stacked PR)
  • 📝 Generate docstrings (commit on current branch)
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch fix/public-openapi-cli-validation

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@openapi/agentstorage.v1.yaml`:
- Around line 211-213: The OpenAPI schema currently has "type: boolean", "enum:
[false]" and "nullable: true" which will still reject null; update the enum to
explicitly include null (i.e., change the enum for the schema that contains
enum: [false] and nullable: true to include null as an allowed value) so
validators and client generators accept nulls alongside false.

In `@packages/cli/src/commands/setup.ts`:
- Around line 123-125: The current code only throws InvalidPayloadError after a
successful res.json() call, so malformed-JSON responses fall through to the
generic network error path; wrap the res.json() call in a try/catch (or use
await res.text() then attempt JSON.parse) when handling the POST /v1/workspaces
response and, on parse failure, throw InvalidPayloadError including the raw
response/text for diagnostics; update the branch that currently throws
InvalidPayloadError (the one referencing InvalidPayloadError and res.json()) to
ensure JSON parse errors are caught and re-thrown as InvalidPayloadError so they
are not misclassified as generic network errors.

ℹ️ Review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9173ba9 and 8396284.

📒 Files selected for processing (2)
  • openapi/agentstorage.v1.yaml
  • packages/cli/src/commands/setup.ts

Comment on lines +211 to +213
type: boolean
enum: [false]
nullable: true
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

OpenAPI 3.0.x nullable true enum specification null validation

💡 Result:

In OpenAPI 3.0.x, nullable: true means null is added to the allowed type, but all other schema constraints still apply—and those constraints can still reject null (the spec explicitly calls this out). So if you also have an enum, validation will only pass for values in that enum; therefore null must be explicitly present in the enum list for null to validate. [1][2]

Example (OAS 3.0.x):

type: string
nullable: true
enum:
  - asc
  - desc
  - null   # must be actual null, not "null"

Many linters/validators enforce this behavior (nullable + enum ⇒ enum must contain null). [2][3]

Sources: OpenAPI Spec v3.0.3 on nullable semantics and constraints [1]; Swagger docs on “Nullable enums” [2]; vacuum linter rule nullable-enum-contains-null [3].


nullable: true with enum: [false] will reject null values.

In OpenAPI 3.0.x, when both nullable: true and enum are specified, null must be explicitly included in the enum array for null validation to pass. The current definition will reject null despite the nullable constraint, causing validator and client-generator mismatches.

Add null to the enum:

Suggested fix
                      type: boolean
-                      enum: [false]
+                      enum: [false, null]
                       nullable: true
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
type: boolean
enum: [false]
nullable: true
type: boolean
enum: [false, null]
nullable: true
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@openapi/agentstorage.v1.yaml` around lines 211 - 213, The OpenAPI schema
currently has "type: boolean", "enum: [false]" and "nullable: true" which will
still reject null; update the enum to explicitly include null (i.e., change the
enum for the schema that contains enum: [false] and nullable: true to include
null as an allowed value) so validators and client generators accept nulls
alongside false.

Comment on lines +123 to +125
throw new InvalidPayloadError(
"POST /v1/workspaces returned an invalid payload.",
);
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Non-JSON success payloads are still reported as “network error.”

InvalidPayloadError is only thrown after a successful res.json() parse. If Line 121 throws (malformed JSON), execution falls through to the generic branch and misclassifies the failure.

💡 Suggested fix
-    const payload = await res.json();
+    let payload: unknown;
+    try {
+      payload = await res.json();
+    } catch {
+      throw new InvalidPayloadError(
+        "POST /v1/workspaces returned a non-JSON payload.",
+      );
+    }
     if (!isCreateWorkspacePayload(payload)) {
       throw new InvalidPayloadError(
         "POST /v1/workspaces returned an invalid payload.",
       );
     }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@packages/cli/src/commands/setup.ts` around lines 123 - 125, The current code
only throws InvalidPayloadError after a successful res.json() call, so
malformed-JSON responses fall through to the generic network error path; wrap
the res.json() call in a try/catch (or use await res.text() then attempt
JSON.parse) when handling the POST /v1/workspaces response and, on parse
failure, throw InvalidPayloadError including the raw response/text for
diagnostics; update the branch that currently throws InvalidPayloadError (the
one referencing InvalidPayloadError and res.json()) to ensure JSON parse errors
are caught and re-thrown as InvalidPayloadError so they are not misclassified as
generic network errors.

@Dan-Cleary Dan-Cleary merged commit 43bb4d2 into main Mar 3, 2026
3 checks passed
@Dan-Cleary Dan-Cleary deleted the fix/public-openapi-cli-validation branch March 3, 2026 19:00
Dan-Cleary added a commit that referenced this pull request Mar 4, 2026
#3)

Replace unsupported OpenAPI const usage with 3.0-compatible enums and make CLI setup report invalid workspace creation payloads explicitly instead of classifying them as network failures.

Made-with: Cursor
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant