-
Notifications
You must be signed in to change notification settings - Fork 251
fix(amazonq): fix chat refresh button #5701
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
Conversation
Previously, the browser waits for the server initialization to succeed before unlocking the loading process. When reloading the webview, since the server has already been initialized, it does not receive an initialization event and is stuck loading forever. Fix by moving to a hot flow that always returns the latest instance of AmazonQLanguageServer. While this could be any value, the idea is to bring us closer to the state where we can tie the lifetime of ChatCommunicationManager to the webview instance so that we can delete AsyncChatUiListener. Additionally this should also address the rare race condition where the server finishes startup before the webview finishes drawing.
Qodana Community for JVM1 new problem were found
💡 Qodana analysis was run in the pull request mode: only the changed files were checked Contact Qodana teamContact us at qodana-support@jetbrains.com
|
scope.launch { | ||
val webUri = service<ArtifactManager>().fetchArtifact(project).resolve("amazonq-ui.js").toUri() | ||
// wait for server to be running | ||
AmazonQLspService.getInstance(project).instanceFlow.first() |
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.
So is this an await equivalent?
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.
flows are like sequences, so this will wait until a value is available. this specific flow is set up to only ever have one value
Previously, the browser waits for the server initialization to succeed before unlocking the loading process. When reloading the webview, since the server has already been initialized, it does not receive an initialization event and is stuck loading forever.
Fix by moving to a hot flow that always returns the latest instance of AmazonQLanguageServer. While this could be any value, the idea is to bring us closer to the state where we can tie the lifetime of ChatCommunicationManager to the webview instance so that we can delete AsyncChatUiListener.
Additionally this should also address the rare race condition where the server finishes startup before the webview finishes drawing.
Known issue is that on refresh, the history is not restored due to a change that needs to be contributed into the Flare server
License
I confirm that my contribution is made under the terms of the Apache 2.0 license.