JS API Error handling #1086
JS API Error handling #1086
Conversation
|
Extremely rough patch for @mofojed to finish up nicely in the UI niloc132/web-client-ui@e798052 |
| @@ -65,6 +67,9 @@ static AuthTokenPromiseSupplier oneShot(ConnectToken initialToken) { | |||
| @JsProperty(namespace = "dh.QueryInfo") | |||
| public static final String EVENT_CONNECT = "connect"; | |||
|
|
|||
| @JsProperty(namespace = "dh.IdeConnection") | |||
| public static final String HACK_CONNECTION_FAILURE = "hack-connection-failure"; | |||
There was a problem hiding this comment.
Why is this named hack-connection-failure? Why hack-?
There was a problem hiding this comment.
I believe 'hack' here is to make it blindly obvious this is a temporary work around to a bigger problem that Colin wants carte blanche to fix correctly.
There was a problem hiding this comment.
This is temporary, until we have reconnect (#730) which will have this being removed. I wanted to draw a distinction between normal events or internal-only ones, but I'm open to some other way to do that.
I tried to summarize in the description above (and will make it part of the actual commit message), but the old reconnect events are probably what we will use for these cases once the api is smart enough to try reconnecting streams.
There was a problem hiding this comment.
Okay cool, I've got a change to listen for these new errors pushed on my Application Mode PR: deephaven/web-client-ui#155
Added basic error handling, but not proper reconnects or reauth. Three error types are handled for the main streams or polling calls:
A new event was added, temporarily, to inform the UI that we are giving up if one of these happens, and the page needs to be reloaded. This will be removed when we have proper reconnect, and inform the UI again that the reconnect succeeded or failed.
Also modified a few errors being sent from the server to hopefully better reflect the intent of the gRPC status codes, and avoid using "INTERNAL" when "something bad" happens.
The UI will need a few small changes to handle this, and to handle a few cases where API calls can fail but not be registered in the UI.
Fixes #1065, but #730 needs to formally address this.