OpenAPI validation errors must be provided as a JSON response

If such errors are always JSON responses, then we can update the work @balintbrews introduced in 📌 Improve client side error handling Fixed to surface a friendlier error than this:

Aha, for #2 we already have ✨ [PP-1] Add the ability to surface more helpful error details for display in the UI Postponed ! 👍

But without a structured error response from the server for the client to consume, fixing #2 is impossible.

IOW: this is a blocker for ✨ [PP-1] Add the ability to surface more helpful error details for display in the UI Postponed .

Wim Leers → credited effulgentsia → .

Wim Leers → credited traviscarden → .

Transfering relevant info + credit from ✨ [PP-1] Add the ability to surface more helpful error details for display in the UI Postponed :

Any path that can result in an exception needs to return well-formed JSON that the UI can interpret as an error message. On the backend, that probably just means creating a new exception class (if one doesn't already exist). On the front-end, it may mean no more than you telling me the JSON format you need for error popups.

One thought I had on what's proposed is that debugging info in case of error responses from the API should be logged on the server side. E.g. a PHP stack trace surfaced in the browser is a security vulnerability.

That's a good point. We already have Drupal logging in place. Now that you point it out, I'm not sure what debugging info would be both safe and helpful in the browser console. Let's start with just the UI error message. Can you tell me how I need to format my JSON error message to be displayed nicely in the UI?

— @traviscarden, #3470321-4: [PP-1] Add the ability to surface more helpful error details for display in the UI →

By the way, there's some prior art in core's jsonapi module for returning a stack trace in the json response if the site is configured to display verbose errors and the user has access to site reports.

So long as we do those two checks, it's safe. But, the question is whether in XB's case if seeing the stack trace in the browser would be helpful or not.

— @effulgentsia, #3470321-5: [PP-1] Add the ability to surface more helpful error details for display in the UI → .

The implementation here:

• tells Drupal which routes return JSON format by setting the _format requirement
• intercepts exceptions for JSON format routes that are named experience_builder.*
• returns the exception message as a simple JSON structure

This is enough to get started on displaying nicer errors on the client. I am not sure a stack trace would be useful to the client but it might be useful to keep in the JSON data for debugging via the network inspector?

A screenshot of this in action, exploiting the crash in 🐛 Emptying a required value through the UI crashes the app Active before that fix is merged:

Simplified this further, we have precedent in XbRouteOptionsEventSubscriber for API routes already so I used that instead - no need to force _format: json (although perhaps we still should for correctness?)

It turns out that EntityFormControllerTest already tests an error that should be returned in JSON format, so I reworked the test case there to expect JSON instead - that should be enough coverage to start with?

I also ported the stack trace functionality from JSON:API module with the same conditions, and the test covers that too.

With a one line change I've exposed the message in the UI if the preview endpoint fails:

I can RTBC this as soon as the (trivial) requested change is made.

Reverted the UI change as it's not TypeScript safe, and should be done in ✨ [PP-1] Add the ability to surface more helpful error details for display in the UI Postponed

Nice. This should immediately improve the experience for everyone.

I don't seem to have the ability to actually merge the MR, so I'll mark this RTBC until I can get it.

Adding @longwave's excellent screenshot from #14 to the issue summary.

I've been trying to get access to merge this MR all day, and despite apparently having all the necessary permissions, I still cannot. So if someone who can merge it kindly would, that would be great. You have my approval to do so.

Merging on behalf of @traviscarden.

Automatically closed - issue fixed for 2 weeks with no activity.