fix(auth): persist plan update even when org fetch fails on self-hosted

[ManthanNimodiya]

Summary

The previous auth loop fix stopped the double deep-link delivery, but auth still didn't persist on self-hosted because of a second bug in update_auth_plan.

When fetch_organizations failed (common on self-hosted where the org endpoint returns an unexpected response), the ? operator bailed early and Self::set(app, Some(auth)) was never called, meaning the plan update was computed but never written to disk.
On next app start, organizations was always empty, hasAvailableOrganizationCache returned false, and the UI showed the login screen even though valid credentials were in the store.

Fix

Treat org fetch failure as non-fatal, log the error, keep existing organizations, and still persist the plan update to disk.

Greptile Summary

This PR fixes a bug in update_auth_plan where a ?-operator early-return on fetch_organizations failure prevented Self::set from ever being called, causing the computed plan update to be silently discarded on self-hosted deployments.

• The fetch_organizations call is now wrapped in a match so failures are logged via tracing::warn! and the existing (stale) organizations are preserved rather than bailing early.
• Self::set(app, Some(auth)) now always executes after the plan fetch, persisting the plan to disk regardless of whether org refresh succeeded.

Confidence Score: 5/5

Safe to merge — the change is a minimal, targeted fix that converts one early-return path to a non-fatal branch, with no impact on the plan-fetch success path.

The fix is small and correct: it ensures the plan is always written to the store regardless of whether org fetch succeeds. When org fetch fails, the in-memory auth already holds the previously stored organizations, so persisting it does not accidentally wipe previously cached org data.

No files require special attention.

Important Files Changed

Filename	Overview
apps/desktop/src-tauri/src/auth.rs	Converts early-return on failed fetch_organizations into a non-fatal warning, ensuring Self::set is always called and the plan update is always persisted to disk.

_{Reviews (2): Last reviewed commit: "fix(auth): use tracing::warn for org fet..." | Re-trigger Greptile}

[greptile-apps]

Use structured logging instead of println!

The rest of the error-path in this function already uses println! (lines 81, 84), so this is consistent — but production Tauri apps typically route log::warn! / tracing::warn! through the platform logging backend (accessible in the DevTools console and system log), whereas println! only appears on stdout. A swallowed org-fetch error that only appears on stdout can be hard to surface in the field, especially on self-hosted deployments where the terminal is rarely visible.

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/desktop/src-tauri/src/auth.rs
Line: 108-110

Comment:
**Use structured logging instead of `println!`**

The rest of the error-path in this function already uses `println!` (lines 81, 84), so this is consistent — but production Tauri apps typically route `log::warn!` / `tracing::warn!` through the platform logging backend (accessible in the DevTools console and system log), whereas `println!` only appears on stdout. A swallowed org-fetch error that only appears on stdout can be hard to surface in the field, especially on self-hosted deployments where the terminal is rarely visible.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[ManthanNimodiya]

@greptileai please re-review