Skip to content

Conversation

@fioan89
Copy link
Collaborator

@fioan89 fioan89 commented Oct 31, 2025

This PR addresses two issues in the URI handler workflow to improve user experience and reliability.

  1. Streamline version fallback behavior
    Problem: When the URI handler receives a build number that is no longer available, the application would fall back to the latest version but display a confirmation dialog. Netflix reported that this confirmation dialog disrupts the user workflow.
    Solution: Removed the confirmation dialog and replaced it with logging. The handler now silently falls back to the latest available version when the requested build number is unavailable, maintaining a seamless user experience.

  2. Fix connect page not displaying when Toolbox is already open
    Problem: When Toolbox is already running and a URI is executed, the connect page fails to display. Investigation revealed that the UI event emitted via MutableSharedFlow(replay = 0) is lost because the UI collector is not yet active when processEvent() is called.
    Solution: Introduced a 66-100ms delay before emitting the UI event. This delay ensures the collector is ready to receive events, preventing them from being dropped. The timing was determined through testing and appears to account for the collector initialization time.

Note: The delay in fix #2 is a workaround for what appears to be a timing issue with the MutableSharedFlow collector initialization.

The URI handler expects a product code a build number. If the build number
is no longer available we defaulted to latest version available and popped
up a confirmation window to make sure the user wants to go forward with
the new version

Netflix pointed out that the confirmation dialog disrupts the workflow.
With this PR we only log that we fall back to latest version available
in order to streamline the handler.
If Toolbox is already opened and URI is executed the setup page
from below is never called. I tried a couple of things, including
yielding the coroutine - but it seems to be of no help. What works
delaying the coroutine for 66 - to 100 milliseconds, these numbers
were determined by trial and error.
The only explanation that I have is that inspecting the TBX bytecode it seems the
UI event is emitted via MutableSharedFlow(replay = 0) which has a buffer of 4 events
and a drop oldest strategy. For some reason it seems that the UI collector
is not yet active, causing the event to be lost unless we wait > 66 ms.
I think this delay ensures the collector is ready before processEvent() is called.
Copy link
Member

@code-asher code-asher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#2 must have been a nightmare to figure out lol

@fioan89
Copy link
Collaborator Author

fioan89 commented Nov 3, 2025

#2 must have been a nightmare to figure out lol

You are on point :) This was raised in the meantime https://youtrack.jetbrains.com/issue/TBX-16622

@fioan89 fioan89 merged commit 81921d7 into main Nov 3, 2025
6 checks passed
@fioan89 fioan89 deleted the improve-uri-handling-workflow branch November 3, 2025 17:31
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