Errors
Design type: Error state | Product area: Hybrid Cloud Console
Author: Kevin Hatchoua
Last edit: March 21, 2023
How to format them depends on the error and context
Although most of these patterns are shown as full-page errors, these empty states can also be used in tables, if there is an error loading content. In that case, the empty state should appear the same way a “No match found” empty state would appear within a table.
500 Error pattern: page unavailable
This error pattern should be used when an error state when an API returns a 500 error (page unavailable). There is an app specific pattern, and a platform wide pattern.
Developers can use the following component to implement this error format.
Application-specific pattern (see Marvel in the link above)
404 Error pattern Out-of-App
This error pattern should be used for 404 errors. This is handled by the platform through Akamai. App teams should not have to worry about handling this.
404 Error pattern In-App
When the error is in the app (coming after the bundle name in the URL) the error page will include the navigation, but the message in the body of the page will remain the same.
403 Error (Authentication)
This error pattern should be used when a user does not have permission to access a page.
Developers can use the following component to implement this error format.
401 Errors (Unauthorized)
There is no “pattern”/component for this error. When a 401 error “happens” a user should just be redirected to the login page. You can access more info on how to do this here.
Errors in a dropdown
This example is where clicking on an icon opens a “dropdown” with options for the user. These options are loaded dynamically and may fail. In that case, we need to show an error state.
The icon is “standard” size, 18x18.
Error state formatted similarly to other error patterns
Catch-all error (Error 4xx, except 404)
This error should be used as a catch-all error pattern when none of the above use cases apply, for all 400 errors, with the exception of 404.
Marvel: https://marvelapp.com/prototype/4je15b3/screen/71643931
A component for developers to use is currently in the process of being created. Issue here.
Post action system error: toast alert
This toast alert error should be used when an action fails for a reason outside of the user’s control (e.g. c.rh.c has an error). This kind of toast error should be used exclusively for SYSTEM errors, never user errors. If the error is caused by the user (e.g.: inputted name is taken) use an inline error at the top of the form/page.
User actions that would trigger this alert could be:
- The user was in a modal, clicked save, and everything validated ok, but then something went wrong
- The user attempted to add something to a table, and it failed
- The user tried to add a User Access group but something went wrong
- Other: Adding an item to a list failed; Deleting an item; Edits did not save; etc
Error level of detail:
- Don’t dump an error code, write it in English, and use generic as backup
- The event log SHOULD have the error code (who should see this log - probably just developers, not the user)
- Examples:
- The baseline failed to delete. There was an error processing the request. Please try again.
- Group creation failed. There was an error processing the request. Please try again later.
System errors can be shown inline if there is a modal/form to show the content in:
More cases:
https://trello.com/c/LY0YjZ8q/1611-discuss-comparison-error-messages
https://github.com/RedHatInsights/policies-ui-frontend/pull/196
Post user input error: inline validation or alert
Please refer to Patternfly form validation guidelines for more information.
This error should be used when there is a problem with user input in a form for example. In the case of a problematic input, you should use field-level errors, and optionally, an inline alert at the top of the form. There are some cases where you may only be able to use an inline alert at the top, however, in most cases, you should always default to field-level errors!
Possible user input errors:
- This role name is already taken.
- This is an invalid email format.
- The email or password is invalid/does not match any existing account.
- This is a required field.
Errors that affect part of the page
Status Error: Table Row
Statuses are common across our products for individual items in a table, which can include systems, clusters, images, etc. Sometimes something can go wrong with that row item. In that case, we show “Error” in the status line.
The error status allows for the list to be sorted, unlike if the exact error status was exposed at this level.
The error can be further described by showing information in a popover and, if relevant, a contextual action can be added.
EXAMPLES:
While other examples can show the error text in an expandable row, popovers can be used on any existing table and allow for contextual actions to be brought to the forefront.
In a table
If a table has a full error, then hide results and column headers.
The toolbar should remain, and any actions that are not possible should be disabled. Any actions that are possible should be enabled.
Why keep the toolbar? The toolbar may contain actions that are still available while the table data is unavailable, such as “Create new”