Better error handling

[desa]

There are a number of places where we do not display the error we get back from the API. This can be confusing to end users. It would be great to have a wholistic approach to how we handle errors in the front-end.

[chnn]

Random thoughts:

• I think the most positive change we can make in the UI is to specify error states in mockups to begin with. We almost never do, and I think the result is engineers not thinking about the error path much (or if they do, it's just to display a notification, which is a bit lazy)

• I've noticed some areas where the API could be more consistent. For example, writing a syntactically invalid Flux query returns a 500 error when a 400 or 422 is likely more appropriate. It also returns the useful error message in the error field on the JSON response, rather than the message field like most other endpoints

• Move API client generation into influxdb #14482 should help us know about what errors we should be handling while in development

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.