Surface backend validation error messages inline in the Create-API wizard#1395
Open
IsuruGunarathne wants to merge 11 commits into
Open
Surface backend validation error messages inline in the Create-API wizard#1395IsuruGunarathne wants to merge 11 commits into
IsuruGunarathne wants to merge 11 commits into
Conversation
…t validation catch
…i-error-handling Improvement UI error handling
When validate-openapi rejects a definition by URL/file (HTTP 400 with a reason in the response body), the wizard's .catch handlers dropped the backend reason to console.error and showed only a generic "validation failed" message - the Validation Errors card stayed empty. A 400 was thus surfaced less prominently than a 200 isValid:false, which renders the backend errors array in the card. Add getValidationErrorsFromError() to thread the backend response.body.description into setValidationErrors() across the URL and file (API + MCP) rejection paths, so a rejected validation shows as prominently as the isValid:false path. Also clear stale validation errors on file-validation success. Errors without a backend description return [] and keep the existing generic-message fallback. Adds a unit test for the helper.
… OpenAPI flow) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…eate step Move validationErrorUtils and ValidationResults out of Create/OpenAPI/Steps into the shared Create/Components directory so both the OpenAPI and WSDL create flows consume them from a common location, and update the imports in ProvideOpenAPI and ProvideWSDL accordingly. WSDL Provide step: - Make the input row full-width and drop the container spacing so the drop zone and the validation results panel match the OpenAPI step layout. - Reset the validation state (results panel, inline error and selected input) when the Input Type or Implementation Type changes, matching the OpenAPI flow, so a stale error no longer lingers after switching modes.
…ontrol-ui Surface backend validation error messages inline in the Create-API wizard
IsuruGunarathne
requested review from
HeshanSudarshana,
Krishanx92,
PasanT9,
RakhithaRR,
ashera96,
hisanhunais,
lasanthaS,
piyumaldk and
tharikaGitHub
as code owners
July 17, 2026 05:19
|
JanithaSampathBandara seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
Contributor
📝 WalkthroughWalkthroughValidation handling now surfaces backend descriptions and messages across API, OpenAPI, WSDL, GraphQL, AsyncAPI, endpoint, and MCP server flows. OpenAPI and WSDL validation results use shared structured error rendering, with localized fallback messages and expanded validation state management. ChangesValidation Error Handling
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant User
participant ProvideOpenAPI
participant ValidationAPI
participant ValidationResults
User->>ProvideOpenAPI: Submit URL or file
ProvideOpenAPI->>ValidationAPI: Validate API definition
ValidationAPI-->>ProvideOpenAPI: Success or backend error details
ProvideOpenAPI->>ValidationResults: Update validation state
ValidationResults-->>User: Show validation status and errors
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
portals/publisher/src/main/webapp/source/src/app/components/Apis/Create/WSDL/Steps/ProvideWSDL.jsx (1)
158-164: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueAlign error message fallback chain with other create-API components.
For consistency with
ProvideOpenAPI,ProvideAsyncAPI, andGenericEndpoint, consider falling back toerror.response?.body?.messageanderror.messagebefore applying the default generic message. This ensures users see relevant network or backend error strings whendescriptionis missing.♻️ Proposed refactor
- let message = intl.formatMessage({ - id: 'Apis.Create.WSDL.validation.error.response', - defaultMessage: 'Error occurred during validation', - }); - if (error.response?.body?.description) { - message = error.response.body.description; - } + const message = error.response?.body?.description + || error.response?.body?.message + || error.message + || intl.formatMessage({ + id: 'Apis.Create.WSDL.validation.error.response', + defaultMessage: 'Error occurred during validation', + });🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@portals/publisher/src/main/webapp/source/src/app/components/Apis/Create/WSDL/Steps/ProvideWSDL.jsx` around lines 158 - 164, Update the validation error handling in ProvideWSDL to use the same fallback chain as ProvideOpenAPI, ProvideAsyncAPI, and GenericEndpoint: prefer error.response.body.description, then error.response.body.message, then error.message, and finally the existing localized generic message.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@portals/publisher/src/main/webapp/source/src/app/components/Apis/Create/OpenAPI/Steps/ProvideOpenAPI.jsx`:
- Line 141: Preserve existing validity state in the URL-validation catch blocks
by spreading isValid before setting the URL error. Update ProvideOpenAPI.jsx
lines 141-141, ProvideAsyncAPI.jsx lines 229-236, and ProvideGraphQL.jsx lines
178-181 so each setValidity call uses the existing isValid state alongside its
current url error payload.
---
Nitpick comments:
In
`@portals/publisher/src/main/webapp/source/src/app/components/Apis/Create/WSDL/Steps/ProvideWSDL.jsx`:
- Around line 158-164: Update the validation error handling in ProvideWSDL to
use the same fallback chain as ProvideOpenAPI, ProvideAsyncAPI, and
GenericEndpoint: prefer error.response.body.description, then
error.response.body.message, then error.message, and finally the existing
localized generic message.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: bce3568d-92a0-40dc-86cf-412e5630b2e2
📒 Files selected for processing (11)
portals/publisher/src/main/webapp/site/public/locales/en.jsonportals/publisher/src/main/webapp/source/src/app/components/Apis/Create/AsyncAPI/Steps/ProvideAsyncAPI.jsxportals/publisher/src/main/webapp/source/src/app/components/Apis/Create/Components/DefaultAPIForm.jsxportals/publisher/src/main/webapp/source/src/app/components/Apis/Create/Components/ValidationResults.tsxportals/publisher/src/main/webapp/source/src/app/components/Apis/Create/Components/validationErrorUtils.test.tsportals/publisher/src/main/webapp/source/src/app/components/Apis/Create/Components/validationErrorUtils.tsportals/publisher/src/main/webapp/source/src/app/components/Apis/Create/GraphQL/Steps/ProvideGraphQL.jsxportals/publisher/src/main/webapp/source/src/app/components/Apis/Create/OpenAPI/Steps/ProvideOpenAPI.jsxportals/publisher/src/main/webapp/source/src/app/components/Apis/Create/WSDL/Steps/ProvideWSDL.jsxportals/publisher/src/main/webapp/source/src/app/components/Apis/Details/Endpoints/GenericEndpoint.jsxportals/publisher/src/main/webapp/source/src/app/components/MCPServers/Create/MCPServerCreateProxy.jsx
| id: 'Apis.Create.OpenAPI.Steps.ProvideOpenAPI.url.validation.error', | ||
| defaultMessage: 'Failed to validate the OpenAPI URL. Please try again.', | ||
| }); | ||
| setValidity({ url: { message: errorMessage } }); |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Preserve existing validation state when setting URL errors.
In the previous implementations, these .catch() blocks used the object spread ...isValid to update the URL error without erasing other tracked validity states (such as isValid.file). The recent refactors dropped this spread, which can cause subtle state-loss glitches when users toggle between input modes.
Please restore the ...isValid spread in these validation catch blocks:
portals/publisher/src/main/webapp/source/src/app/components/Apis/Create/OpenAPI/Steps/ProvideOpenAPI.jsx#L141-L141:setValidity({ ...isValid, url: { message: errorMessage } });portals/publisher/src/main/webapp/source/src/app/components/Apis/Create/AsyncAPI/Steps/ProvideAsyncAPI.jsx#L229-L236: Update tosetValidity({ ...isValid, url: { ... } });portals/publisher/src/main/webapp/source/src/app/components/Apis/Create/GraphQL/Steps/ProvideGraphQL.jsx#L178-L181: Update tosetValidity({ ...isValid, url: { ... } });
📍 Affects 3 files
portals/publisher/src/main/webapp/source/src/app/components/Apis/Create/OpenAPI/Steps/ProvideOpenAPI.jsx#L141-L141(this comment)portals/publisher/src/main/webapp/source/src/app/components/Apis/Create/AsyncAPI/Steps/ProvideAsyncAPI.jsx#L229-L236portals/publisher/src/main/webapp/source/src/app/components/Apis/Create/GraphQL/Steps/ProvideGraphQL.jsx#L178-L181
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@portals/publisher/src/main/webapp/source/src/app/components/Apis/Create/OpenAPI/Steps/ProvideOpenAPI.jsx`
at line 141, Preserve existing validity state in the URL-validation catch blocks
by spreading isValid before setting the URL error. Update ProvideOpenAPI.jsx
lines 141-141, ProvideAsyncAPI.jsx lines 229-236, and ProvideGraphQL.jsx lines
178-181 so each setValidity call uses the existing isValid state alongside its
current url error payload.
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
3 participants
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.
Surface backend validation error messages inline in the Create-API wizard
Purpose
When a submitted API definition or endpoint is rejected by the backend, the Create-API wizard previously either swallowed the server's message or replaced it with a generic one, so the user could not tell why the input was rejected. This change surfaces the backend's validation error message inline, next to the relevant step, across every definition type in the wizard.
What changed
ValidationResultspanel and avalidationErrorUtilshelper (with unit tests) underApis/Create/Components, so every create flow renders backend validation errors the same way.ValidationResultspanel, matching the OpenAPI flow.GenericEndpoint,DefaultAPIForm, and the MCP server create proxy preserve the server-provided message in the validation catch path rather than overwriting it.en.json.Notes
This branch aggregates the UI error-handling work that was reviewed and merged into the
feature_nw_access_controlbranch (the base error-handling improvements plus the inline error-surfacing on top). It pairs with the corresponding backend validation changes; the UI degrades gracefully if the backend returns a generic message.