fix(lsp): Catch cancellation exceptions thrown by TSC, stop waiting for TS result upon cancellation #23645
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #23643.
We weren't catching the cancellation exception thrown by TSC on the JS side, so the rust side was catching this exception and then attempting to print out the exception via
toString
. That last bit resulted in a cryptic[object Object]
showing up in the logs like so:I'm not 100% sure how we weren't seeing this in the past. My guess is that #23409 and the subsequent PR to improve the exception catching and logging surfaced this, but I'm still not quite clear on it.
My initial fix here returned
null
to rust when a server request was cancelled, but this resulted in a deserialization error when we attempted to deserialize that into the expected response type. So now, as soon as the request's cancellation token signals we'll stop waiting for a response and return an error (which will get swallowed as the LSP request is being cancelled).I was a bit surprised to find that this branch actually executes sometimes, I believe due to the fact that aborting a future may not immediately stop its execution.