fix(gui-client): don't busy-loop when update checker is disabled

[thomaseizinger]

The GUI client's update checker is a task that runs concurrently to the main event-loop of the client. When a new update is found, it sends a notification through a channel. When the update checker is disabled via MDM, this channel is instantly closed, resulting in None being read as part of the event-loop in the client.

Previously, we would then return Poll::Ready(EventloopTick::UpdateNotification(None)) and then simply ignore this event. This however is wrong. Returning Poll::Ready means that the future needs to be polled again, resulting in an effective busy-loop where we constantly emit the above event and then ignore it. Due to the priority order that was previously defined, this led to us never checking another channel: The one where we receive deep-links from 2nd GUI instances.

As a result, signing into the client when the update checker was disabled does not work and instead, the newly launched instance hangs because it can never send over the deep-link.

Resolves: #9420

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
firezone	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 6, 2025 8:56am

[Copilot]

Pull Request Overview

This PR prevents a busy-loop when the update checker is disabled by flattening the nested Option for update notifications and reprioritizing channels so new-instance deep-links are still handled.

• Simplified UpdateNotification variant from Option<Option<...>> to Option<...>
• Changed the event-loop from while let Some(...) to an infinite loop with a match on a non-optional tick
• Reordered tick so NewInstanceLaunched is polled before update notifications

Comments suppressed due to low confidence (3)

rust/gui-client/src-tauri/src/controller.rs:396

• [nitpick] Consider adding a comment here explaining that update notifications are intentionally deprioritized and that closing the updates channel should not cause a busy-loop.

if let Poll::Ready(Some(notification)) = self.updates_rx.poll_next_unpin(cx) {

rust/gui-client/src-tauri/src/controller.rs:297

• Add a test case simulating the update-checker being disabled (updates_rx channel closed) to verify that the controller does not busy-loop and still processes deep-link events.

loop {

rust/gui-client/src-tauri/src/controller.rs:340

• [nitpick] The name notification here represents an Option<updates::Notification>. For clarity, consider renaming it to maybe_notification or notification_opt.

EventloopTick::UpdateNotification(notification) => {