-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make command handling in Q chat webview async #35
Conversation
|
||
public ChatMessageProvider() { | ||
try { | ||
amazonQLspServer = LspProvider.getAmazonQServer().get(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this the root cause of the deadlock between the LSP and Client startup?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this blocking call was preventing download and startup from happening.
plugin/src/software/aws/toolkits/eclipse/amazonq/views/AmazonQChatViewActionHandler.java
Outdated
Show resolved
Hide resolved
} | ||
public static CompletableFuture<ChatMessageProvider> createAsync() { | ||
return LspProvider.getAmazonQServer() | ||
.thenApply(ChatMessageProvider::new); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ahh I see. That makes sense.
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.