Handle cancelRequest from lsp4ij#410
Conversation
… notifications to DAS as legacy server.cancelRequest to prevent request backlog and server OOM
…ful cancellation forwarding does not log unhandled message warning
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request implements support for request cancellation in the DartVirtualStreamConnectionProvider by maintaining a mapping between LSP request IDs and legacy Dart Analysis Server IDs. The reviewer identified a logic bug where handled cancellation requests would still be logged as ignored, a potential null pointer exception when processing message parameters, and a performance concern regarding the O(N) complexity of the current ID lookup strategy.
… robust null check and type verification
…response hot path O(1) lookup and removal
|
@gemini-code-assist comments have been addressed; can you review again? |
There was a problem hiding this comment.
Code Review
This pull request implements support for forwarding LSP cancellation requests to the legacy Dart Analysis Server by updating the pendingLegacyIds storage to a map that tracks the mapping between legacy and LSP request IDs. Feedback was provided regarding a potential string conversion mismatch for numeric IDs and the performance implications of the linear search used to resolve IDs during cancellation.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
2 participants
Not having cancelRequest forward to the DAS was causing problems as I was working on
codeActionbecause it can cause DAS to crash when there are many requests. However,cancelRequestis independent fromcodeActionand makes sense to have first.Note that this is sending a legacy
cancelRequest, not LSP-over-legacy.