Display validation errors in dialogs that create sections

Currently sending a machineName that's already taken results in a 500 error, which Wim already explained in a Slack conversation that:

We'll need to change that to return a 409 (conflict).

Besides the 422 error, what other errors can we expect?

No other HTTP status codes; you should only see 409 and 422.

Note: I agree the value is currently limited. But as soon as #3500017: Defining props for code components lands, there'll be even more possibilities for validation errors: props must be named in a particular way, for example (just like machineName in the example above). And the name of a prop must not be used by a slot, and vice versa.

So: the more complete #3499919: [Meta] Plan for in-browser code components becomes, the more valuable this becomes.

For more context:

1. 🐛 \Drupal\experience_builder\Controller\ApiConfigControllers::post() should generate a 409 for a duplicate entity ID!
2. the test cases in \Drupal\Tests\experience_builder\Kernel\Config\JavaScriptComponentValidationTest::providerTestEntityShapes() that start with the string 'Invalid: for a sense of what validation errors could occur.
3. ⚠️Note that this relies almost completely on SDC's metadata validation, which itself is incomplete/inaccurate — for example #3493086: SDC DX does not inform about invalid JSON schemas.
4. the end-to-end HTTP API test coverage for these config entities — which is nowhere near as complete as I'd like — at \Drupal\Tests\experience_builder\Functional\XbConfigEntityHttpApiTest::testJavaScriptComponent(). I know for sure that the renaming/remapping in \Drupal\experience_builder\Entity\JavaScriptComponent::normalizeForClientSide() is not being respected when generating validation errors, so a validation error for a key the client sent may return a validation error for a different key: in the server-side representation. \Drupal\experience_builder\Controller\ApiConfigControllers should be using ConstraintPropertyPathTranslatorTrait but doesn't yet.

… but none of that is actually a blocker for this issue — this issue can pretend none of those problems exist, and in a future server-side issues we can fix all that — when somebody runs into it :)

Did you see

2. Bonus: use the pattern attribute for providing client-side validation, to make the user immediately aware? 🤓

?

That'd literally prevent the 422 in the screenshot from ever occurring!

Created issue for #3.1: #3504366: ApiConfigControllers::post() should detect a conflicting ID and throw a 409 exception.

It's possible to run into the same problem for the "section" creation dialog: #3504434: ConstraintViolationException: Validation errors exist when creating section.

Currently sending a machineName that's already taken results in a 500 error […]

Fixed: #3504366: ApiConfigControllers::post() should detect a conflicting ID and throw a 409 exception 😊

So #3.1 is fixed, the rest isn't yet.

(That also now guarantees that 422 responses follow that helpful format — thanks to tightening /openapi.yml.)

#8: that particular error seems a duplicate of #3509608: Unable to save an optional image with its default value (because it does not correspond to a Media entity): allow saving DefaultRelativeUrlPropSource. See this issue's summary: this is about generally actually displaying validation errors.

Will re-post your comment there and credit you 👍

FYI: #3514035: Creating multiple components with same label causes error: entity with ID already exists was created for a subset of what this issue is about — specifically the 409 (conflict) case that @balintbrews surfaced in #2.

All of the following call for this to be implemented:

• #3514025: Special characters cause regex error when creating code components
• #3520698: Cannot add component to the component library using the contextual menu
• #3520706: Can't add in-browser code component with checkbox prop to the library
• … and more

That would increase the quality/detail of many bug reports.