fix(gui-client): defer GUI exit until tunnel closes#6874
Conversation
…n on Windows Closes #6873 ```[tasklist] - [ ] Minimize diff - [ ] Update changelog ```
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
Is it worth adding testing around |
| TunnelReady { | ||
| resources: Vec<ResourceDescription>, | ||
| }, |
There was a problem hiding this comment.
Not sure why cargo fmt changed its mind on this
| } | ||
|
|
||
| /// True if we should react to `OnUpdateResources` | ||
| fn needs_resource_updates(&self) -> bool { |
There was a problem hiding this comment.
Unrelated refactor but wasn't quite big enough to split out
| <ChangeItem enable={title === "Windows"} pull="6874"> | ||
| Fixes a delay when closing the GUI | ||
| </ChangeItem> |
There was a problem hiding this comment.
I couldn't replicate it on the Headless Client, this is explained by the Headless Client not having the IPC boundary, so it's just one thread and doesn't race between shutting down connlib and shutting down Sentry.
All I can think for the Linux GUI Client is that Linux shuts down a lot quicker, so there is a race but it never happened to trigger for me.
thomaseizinger
changed the title
thomaseizinger
changed the title
|
I slightly reworded the title, hope you don't mind :) |
| return self | ||
| .handle_connect_result(result) | ||
| .await | ||
| .map(|_| ControlFlow::Continue(())) |
There was a problem hiding this comment.
I tried a couple different things, including return Ok(ControlFlow::from(self.handle_connect_result(result).await?));, and none of them compiled?
ReactorScram
changed the title
|
I reworded it again, we aren't actually waiting for the IPC service itself to stop, we're waiting for the tunnel to close down |
Co-authored-by: Thomas Eizinger <thomas@eizinger.io> Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
ReactorScram
changed the title
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
2 participants
Closes #6873
The issue seems to be a race between flushing Sentry in the GUI process and shutting down Firezone in the tunnel daemon (IPC service).
With this change, the GUI waits to hear
DisconnectedGracefullyfrom the tunnel daemon before flushing Sentry, and the issue is prevented.Adding the new state and new IPC message required small changes in several places