Skip to content

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

Merged
merged 5 commits into from
May 9, 2025

Conversation

rli
Copy link
Contributor

@rli rli commented May 9, 2025

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.

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.
@rli rli requested review from a team as code owners May 9, 2025 00:49
Copy link

github-actions bot commented May 9, 2025

Qodana Community for JVM

1 new problem were found

Inspection name Severity Problems
Unused symbol 🔶 Warning 1

💡 Qodana analysis was run in the pull request mode: only the changed files were checked
☁️ View the detailed Qodana report

Contact Qodana team

Contact 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()
Copy link
Contributor

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?

Copy link
Contributor Author

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

@rli rli merged commit 6276aa1 into feature/q-lsp-chat May 9, 2025
14 of 16 checks passed
@rli rli deleted the rli/fix-browser-refresh branch May 9, 2025 20:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants