Uh oh!
There was an error while loading. Please reload this page.
Make command handling in Q chat webview async - #35
Conversation
| public ChatMessageProvider() { | ||
| try { | ||
| amazonQLspServer = LspProvider.getAmazonQServer().get(); |
There was a problem hiding this comment.
Was this the root cause of the deadlock between the LSP and Client startup?
There was a problem hiding this comment.
Yes, this blocking call was preventing download and startup from happening.
Uh oh!
There was an error while loading. Please reload this page.
| } | ||
| public static CompletableFuture<ChatMessageProvider> createAsync() { | ||
| return LspProvider.getAmazonQServer() | ||
| .thenApply(ChatMessageProvider::new); |
There was a problem hiding this comment.
This looks to be the root of the change. Not entirely familiar with how JVM handles async but is thenApply thread safe somehow? How does it prevent deadlock in this case.
There was a problem hiding this comment.
thenApply runs once the future is resolved. Primary thing here is to avoid a blocking call in the constructor run on the main thread. This pattern gives consumers a way to safely construct an instance in an async flow by making the resolution explicit.
Description of changes:
I ran into an issue where the call to get the Q LSP was creating a deadlock in the IDE's ability to fetch and start the language server. Any LSP dependencies should be async/handled in a separate thread. This change makes communication with the chat LSP async.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.