Custom Error Messages - SQL Lab Errors

[benceorlai]

Overview

Motivation / Problem to solve / Target Users

This project was started in mid-2020 at Airbnb. The motivation was to improve the way error messages are handled, parsed, and brought to the user's attention throughout the Superset UI. In its original state, the way the application would display error messages was not consistent and did not provide sufficient details to make them actionable for the user. This would result in sub-optimal UX as well as unnecessary user service requests to the helpdesk or the original creator of a query, chart, dashboard, etc.

An error can occur in Superset due to one of many reasons:

• Data fetch errors: the client was unable to fetch the requested data, usually due to a connection error
• Access Denied Errors: the user does not have the right privileges to see the requested resource
• Query Syntax Errors: the query has syntax errors
• Out of date query Errors: the data structure has changed and the requested data is not available anymore
• Timeout Errors: the query took too long to complete
• Database engine errors: the database engine encountered an error
• Other errors

Summary of proposed solution

Two SIPs were raised to create a comprehensive solution for this project:

• Proposal for Custom Error Messages (SIP-40) - proposes a unified pattern for handling API errors on the frontend
• Proposal for Alignment of Backend Error Handling (SIP-41) - ensures that all API errors are handled using the same handling mechanism, improves documenting which exception a method raises, and removes unnecessary redirection and obfuscation with error handling

The scope of this project is to implement these improvements in the SQL Lab application. Given that the SQL Lab code base is old, it warrants its own project to improve error handling. The most common error types in SQL Lab are:

• SQL query syntax errors - the query is not properly written, this usually generates an error message from the database engine
• Access errors - the user does not have access to a resource, this usually generates an error message from the database engine
• Database engine errors: the database engine encountered an error
• Network connection errors: the client's internet connection is interrupted

When an error message is displayed in SQL Lab, it should

• Be clearly formatted and structured, by following the same UI design established for the rest of the project
• Wrap error message in

   tag for proper formatting

• One of the most frequent error message types is database errors
• For database errors
  • Enable per database custom error handling, e.g. Presto, Hive, Big Query, Redshift etc
  • Inform the user that the error message was returned from the database (as opposed to being an error in the Superset application)
  • Parse the DB error for standard error code e.g. 400 and highlight it for the user
  • Return full error message by default
  • If full error message is long, allow user to minimize/collapse it in the UI to hide long text

[etr2460]

Can we confirm in the solution that this will conform to the API spec in SIP-40? I want to ensure that it's easy for deployments to override these errors if they so choose within their config overrides

[benceorlai]

@etr2460

@yousoph is the PM on this project, I'll make sure she is aware and that we follow SIP-40 during implementation