[discuss] Improve UX when async chunks fail to load

[lukeelmers]

When running zero-downtime upgrades, users who currently have Kibana opened in their browser will encounter errors as the server rolls over to a new version because of the way that we serve static assets. The most likely scenario is that they will begin getting 404s as webpack attempts to load async chunks, since the URLs to the static bundles will have changed. The resulting error could look something like this:

To fix the issue, users need to simply refresh the page, but an error like this does not help them understand what to do. We should improve the UX so that users aren't seeing an ugly stack trace.

These errors are coming from an EuiErrorBoundary, which handles uncaught exceptions in a portion of the React tree. Unfortunately, there is no centralized place where we are controlling such errors as they could appear anywhere in the UI where we are doing an async import. A quick grep of the codebase shows about 78 different (non-test) files that are using EuiErrorBoundary. Changing the UX would require updating each of those instances with special error handling logic, since EuiErrorBoundary is only capable of rendering the actual Error that's thrown.

Ultimately we need to address two questions here:

1. What should the UX be? I'd suggest that it shouldn't show a stack trace by default, but allow the ability to expand and view it for debugging purposes. For 404s on async chunks it would also be good to show a Refresh button.
2. How would we actually implement? The most obvious idea is wrapping EuiErrorBoundary and sharing it as a component for all apps to use so we could control it globally, but I'm sure there are other options we could consider.

--

Looping in a few folks who I think will care about this: @clintandrewhall @ryankeairns @sophiec20 @rayafratkina

[ryankeairns]

In chatting with @clintandrewhall , my understanding is that the UI becomes altogether unresponsive, so I'm inclined to recommend we hide all of the now-non-functioning elements. This would mitigate additional frustration from wasted clicks.

Consider this a quick wireframe, but perhaps something as simple as:

• Copy is for example purposes
• Send diagnostics is a suggestion; something Clint mentioned as a nice-to-have
• The expanded view of the stack trace could look like:

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[lukeelmers]

I think this will be resolved as a part of https://github.com/elastic/kibana-team/issues/646 -- is that correct @vadimkibana? Should we close this as a duplicate?

[tsullivan]

@lukeelmers yes, please let's close this as duplicate of https://github.com/elastic/kibana-team/issues/646