Groovy parser error kills web UI #3270
Comments
|
Just to clarify, this kills the web UI server, right? Refreshing the page does not fix it? Want to make sure it's not a UI issue |
|
@mattrunyon This kills the connection which kills the web UI, but refresh does fix the issue. @devinrsmith It's complaining about the char
Expected Results Actual Results I think there's two separate issues here that should be addressed:
I'll leave this ticket open for the autocomplete parser |
|
This should be fixed on the web side, it was just fixed after the latest core release. |
|
Investigated from the Web UI side, and it is indeed replacing the non-breaking spaces with regular spaces, but that happens after the text has already been sent for autocomplete (it replaces spaces using an So there's just one issue - the autocomplete parser on the server when there's a non-breaking space dies. @devinrsmith Where is the text you're copying from? Annoying that it has non-breaking spaces. |
|
@mofojed I was coping from the web UI itself; so somehow the non-breaking space got into there, b/c I wrote this code completely within the web UI. Or maybe I didn't even copy it - it might have been from the web UI command history. I forget exactly. |
|
Note: this was triggered on a recent branch off of main. web UI version: 0.24.0. |
|
Note that the ClosedChannelException spam will be fixed by #3278, and signifies nothing beyond "the client disconnected while the server was preparing to send a message". |
|
I'm noticing that this kills the web UI if the first character is NBSP; but not later characters, afaict. |
|
Several bugs happening here. Autocomplete parser tries to parse the string, and fails. Sometime after the last "should I stop?" check but before the error message is finished being sent, the parser thread gets a "nevermind, new characters incoming" with an interrupt from the grpc stream that asked for autocomplete to begin with. Resolution for this is probably to change the grpc impl of LogBufferRecordListener to enqueue log messages and send them to the client in a different thread. Probably just one queue, to all currently connected clients? Next, as a result of the interrupt, an interrupt exception was caught in the websocket implementation of The transport-specific cancel management code for the websocket impl is based on the grpc-servlet project, so we might have a bug to fix there too, and should confirm the behavior of the reference implementation. Lastly, so far anyway, the typescript grpc-web client we're using seems to not detect headers for server-streaming responses. This only applies to websockets, the fetch and xhr implementations are correct here. Failure to detect and report those headers means that when the stream cleanly closes from the server's perspective, the client's internals believe that something went wrong due to the lack of any headers by the time the trailers arrive, and respond with an error. This will be hard to uniformly fix without forking or otherwise replacing the library, as they no longer seem to be making releases, but we might be able to allow this specific error and treat it as success instead. |
|
I believe @niloc132 will be linking some other issues / PRs from this issue. |
This error seems to kill the websocket connection, and then causes an issues w/ gRPC websocket mulitplex:
The text was updated successfully, but these errors were encountered: