summaryrefslogtreecommitdiff
path: root/cli/errors.rs
diff options
context:
space:
mode:
authorNathan Whitaker <17734409+nathanwhit@users.noreply.github.com>2024-05-01 20:31:11 -0700
committerGitHub <noreply@github.com>2024-05-01 20:31:11 -0700
commit66b66de96a78af6162e581c2986e3ef4ec8733c4 (patch)
treec2cab8f3badfb912df0b6961223804d2e73ebf1e /cli/errors.rs
parentee122c5af6b8251329c213b4042a6d71ff5d9b71 (diff)
fix(lsp): Catch cancellation exceptions thrown by TSC, stop waiting for TS result upon cancellation (#23645)
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: ``` Error during TS request "getCompletionEntryDetails": [object Object] ``` 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](https://github.com/nathanwhit/deno/blob/0c671c9792ac706c1ecd60f88efdc5eb8e941917/cli/lsp/tsc.rs#L1093) actually executes sometimes, I believe due to the fact that aborting a future may not [immediately stop its execution](https://docs.rs/futures/latest/futures/stream/struct.AbortHandle.html#method.abort).
Diffstat (limited to 'cli/errors.rs')
0 files changed, 0 insertions, 0 deletions