Add the ability to surface more helpful error details for display in the UI

Assigning to @balintbrews to flesh out any front-end details and issue metadata.

📌 Also validate request bodies against the OpenAPI spec Downport should land before we can work on this. I also recommended in that issue 📌 Also validate request bodies against the OpenAPI spec Downport that we implement the backend side as part of that scope, then we can focus on the required client-side changes in this issue. We need to know the shape of the response in case of errors, then this will come down to making ErrorBoundary.tsx smarter about what kind of error types and shapes it can handle, and consolidating how user facing messages are constructed.

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. Though I'm curious what debugging info you had in mind — there might be interesting use cases I'm not thinking about.

📌 Also validate request bodies against the OpenAPI spec Downport should land before we can work on this.

I actually don't think it's a prerequisite because it's not really specific to that issue. 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?

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.

#5++

On the backend, that means adding a new exception that takes additional details, i.e., the user-facing error message and the console debugging details, and returns it in the form of JSON.

I created 🐛 OpenAPI validation errors must be provided as a JSON response RTBC for that yesterday, independently of this issue. (Another issue/MR was stuck on getting tests to work, and if the error response had been more explicit, it'd have been trivial.)

So let's keep this issue scoped to only:

On the front-end, that means translating the JSON into the error modal and console log.

Moved #4 + #5 to #3470995-6: OpenAPI validation errors must be provided as a JSON response → . Let's keep this focused on the client side, and hence assigned to @balintbrews.

I agree with @traviscarden in #4 that this isn't blocked on 📌 Also validate request bodies against the OpenAPI spec Downport , but it is now blocked on 🐛 OpenAPI validation errors must be provided as a JSON response RTBC .

Marked 🐛 Blocks screen when error encountered Closed: duplicate as a duplicate of this.

🐛 OpenAPI validation errors must be provided as a JSON response RTBC is RTBC so this can be worked on now to expose JSON error messages to the user where necessary.

Server-side support aka 🐛 OpenAPI validation errors must be provided as a JSON response RTBC landed. Which means this is unblocked.

This is critical to improve the productivity of people working full-time on XB, but also to improve the quality of bug reports.