[PP-1] Add the ability to surface more helpful error details for display in the UI

Created on 26 August 2024, 23 days ago
Updated 3 September 2024, 16 days ago

Overview

PHP exceptions currently bubble up to error messages like the following in the UI. This will be confusing to end users, and it's not very helpful for local development.

Proposed resolution

I propose doing two things:

  1. Add exception-handling with human-readable error messages for end users
  2. Output additional debugging info to the browser console for developers

β†’ πŸ› OpenAPI validation errors must be provided as a JSON response Active

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

User interface changes

UI changes are explicit in the proposal above.

✨ Feature request
Status

Postponed

Component

User interface

Created by

πŸ‡ΊπŸ‡ΈUnited States TravisCarden

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Sign in to follow issues

Comments & Activities

  • Issue created by @TravisCarden
  • Assigned to balintk
  • πŸ‡ΊπŸ‡ΈUnited States TravisCarden

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

  • Status changed to Postponed 23 days ago
  • πŸ‡­πŸ‡ΊHungary balintk

    πŸ“Œ 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.

  • πŸ‡ΊπŸ‡ΈUnited States TravisCarden

    πŸ“Œ 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?

  • πŸ‡ΊπŸ‡ΈUnited States effulgentsia

    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.

  • πŸ‡§πŸ‡ͺBelgium Wim Leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί

    #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 Active 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 Active .

  • πŸ‡§πŸ‡ͺBelgium Wim Leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί

    Marked πŸ› Blocks screen when error encountered Closed: duplicate as a duplicate of this.

Production build 0.71.5 2024