Kibana: [Lens] Confusing behavior if Lens vis fails because of non OK http status code

[flash1293]

Kibana version: 7.9.1

Describe the bug:

If the user is missing permissions to access to an index and the request behind a Lens visualization is failing with a 403 status code, Lens is only rendering a technical and unhelpful error message.

There are possibly also other scenarios triggering a similar behavior (e.g. on timeouts)

Steps to reproduce:

1. Create a Lens dashboard based on an index
2. Create a user without read rights on that index
3. Access the dashboard logged in as that user
4. Empty error message is shown

Expected behavior:

1. Clear error message warning the user about missing permissions

Screenshots (if relevant):

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[wylieconlon]

I think the most helpful way of presenting this error message would be if we could get status codes for failures from esaggs. This isn't the only type of failure, but I imagine there are several where we'd want to show Lens-specific errors. Something like:

• Lacking index permissions
• Malformed request (probably a few types of these)
• No results
• ...?

[flash1293]

cc @elastic/kibana-app-arch is there an approach how to improve the message you can recommend?

[lukeelmers]

I was just talking about error handling in expressions with @lizozom yesterday. I think there's more we can do here to surface additional data about the errors from our data retrieval expression functions.

is there an approach how to improve the message you can recommend?

The one thing you could to today is provide a custom onRenderError to the expression loader to hook into errors and decide whether or not to surface them in the UI. If you don't provide it, the toast is popped up by default. Here's an example from the visualize embeddable... not sure if lens is using this yet: https://github.com/elastic/kibana/blob/e6e7187b03554b8b4f3c8846ae2bfec8052fc5f8/src/plugins/visualizations/public/embeddable/visualize_embeddable.ts#L300-L305

But of course, this is only useful if ExpressionRenderError has the data you need. At a minimum I would say it makes sense to include a status code in any errors from essql, esdsl, and esaggs, but would need to think more about how exactly we'd want to implement this in practice.

[flash1293]

We are using renderError of the expression renderer component: https://github.com/elastic/kibana/blob/3dea4444b9bbc5dd9ff04d8517ff86d66f4de563/x-pack/plugins/lens/public/editor_frame_service/editor_frame/workspace_panel/workspace_panel.tsx#L282

[lizozom]

@flash1293

I just added the original Error to the ExpressionValueError because of similar issues in Dashboard and Visualize.
Maybe it can help you? https://github.com/elastic/kibana/pull/77788/files#diff-60877e7a9481c3e959d1e27b8f7e4a7cR33

[flash1293]

Thanks @lizozom - I set up a PR here: https://github.com/elastic/kibana/pull/79831 It required some additional changes to pass it through all the way. We can discuss on the PR if there are concerns with the approach.