-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Display deephaven.ui widget errors in a panel so user can see them #436
Conversation
- Add an error listener to a command - WIP, does not actually display the error yet but is wired up to listen to it. - Need to pass the error down to `DocumentHandler`? Or have a separate `DocumentErrorHandler` widget?
- Errors now display in a panel - Still need to clean up the look of it, add a Reload button
- TODO: Fix the Reload button. Doesn't quite seem to be working.
- We just send a state reset to the object on the server
- If we're currently re-rendering we shouldn't emit the close
- If a callback throws, display a document error
- It could be possible for a component to expect an error to be thrown and it could handle that exception... I don't think we should handle this right now. May revisit later.
- Will fill the contents of the panel if necessary
plugins/ui/src/deephaven/ui/object_types/ElementMessageStream.py
Outdated
Show resolved
Hide resolved
# Something catastrophic happened, log it and close the connection | ||
logger.exception(e) | ||
self._connection.on_close() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there an example of something that can cause this? Just want to test it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mmmm I can't think of a way it could raise an exception right now... but I want to make sure we don't log the error at all. Uncaught exceptions on submit_task
are not logged and do not shut down the system: deephaven/deephaven-core#5192
I'll add that note to the comment, this is more just to be safe. Really, the issue above should be fixed and then this should be removed (because the server will just shut down at that point).
plugins/ui/src/deephaven/ui/object_types/ElementMessageStream.py
Outdated
Show resolved
Hide resolved
request = self._make_notification( | ||
"documentError", | ||
json.dumps( | ||
{ | ||
"message": str(error), | ||
"type": type(error).__name__, | ||
"stack": stack_trace, | ||
"code": ErrorCode.DOCUMENT_ERROR.value, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be in the JSON schema? I don't think we're using it really, but probably not bad to keep it updated unless you don't think we should use schema checking at some point in the future
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it should be, good call.
/** | ||
* Component that displays an error message in a textarea so user can scroll and a copy button. | ||
* TODO: Use the one from @deephaven/components when it's merged: https://github.com/deephaven/web-client-ui/pull/1965 | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Going to leave this for review in the web-client-ui PR
If you want to test w/ the component, you can externalize @deephaven/components
in vite instead of copying the component into dh.ui. Then just import it from @deephaven/components
. It's provided via remote-component.config.ts
in app-utils
- They're not quite correct yet, but I want to refactor some other things first.
- Now it will just render as an overlay for any panels that are open, rather than closing/re-opening panels
- No longer needed now that we have overlay rendering over existing content
- Now it will check that the error cases are displayed correctly
- Still need the package to be published
plugins/ui/src/js/package.json
Outdated
"@deephaven/jsapi-bootstrap": "^0.74.0", | ||
"@deephaven/jsapi-components": "^0.74.0", | ||
"@deephaven/chart": "^0.73.0", | ||
"@deephaven/components": "^0.73.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now we probably do want to bump these to use the ErrorView
from @deephaven/components
@@ -0,0 +1,13 @@ | |||
/** A panel that uses the ReactPanelContentOverlayContext and if that content is set, renders it in a view with a partially transparent background */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this comment needs to go above the component, not at the top of the file
Noticed #85 is also fixed by this PR The styling is inconsistent between components that didn't render and components that did Different background color on the right and darker looking overlay |
@mattrunyon On the right it is overlaid on top of content, so it appears as a shade. This is akin to when we have a table that doesn't open because of an error, and a table that gets an error, e.g.: For IrisGrid we use 10% (which I think is incorrect): https://github.com/deephaven/web-client-ui/blob/3de52d6fa0512792c97928f65f0b4b1080da2c49/packages/components/src/LoadingOverlay.scss#L5 For ChartPanel we use 50% (which is probably better): https://github.com/deephaven/web-client-ui/blob/3de52d6fa0512792c97928f65f0b4b1080da2c49/packages/dashboard-core-plugins/src/panels/ChartPanel.scss#L5 And then here I've got 90%. @dsmmcken Which scrim % should be used in these cases? |
In my pictures with and without content, both panels have the same color (look at the bottom of the panels). So I think that the opacity is applied at the wrong element or is not being applied if there's no content. |
@dsmmcken here it is with 50%, what do you think? |
@mattrunyon the error overlays overtop of the content if it exists and that's when a transparency is applied. |
The error box itself should be more opaque (the red). If you had a more complex component under it, I think it might be too low contrast and too hard to read |
- Blends better with light themes
@mattrunyon Don approved with the blur. |
Ok. I'm still not a fan of the red text on transparent red background. Seems like it's still too low contrast, but I'll defer to Don on this one |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both light and dark theme with and without content fail the chrome contrast ratio test for accessibility (I checked the contrast ratio on the "ValueError" span w/ dev tools).
That said, it's not worth holding this up since it should be fine in most cases still. And it would be a change in web-client-ui to fix the contrast of ErrorView
@mattrunyon there's a PR for improving error view in web-client-ui: deephaven/web-client-ui#2001 |
- Reverted package-lock.json to before deephaven#436 - Fixed the jsapi-types stuff, then do an npm install to re-update the package-lock.json
- Reverted package-lock.json to before #436 - Fixed the jsapi-types stuff, then do an npm install to re-update the package-lock.json
documentError
on the server to indicate there was an error rendering the documentdocumentError
and will display the error message in a panel along with a Reload button to reload the widget@deephaven/*
packages to 0.76.0, which includes theErrorView
and is also in deephaven-core 0.34.1ui_boom
andui_boom_counter
components: