Fix: forced re-login on cold start when radiance core not yet ready

[david-lant]

Summary

Auto-fix for Freshdesk ticket #180375.

Chinese Android Pro user on v9.1.15 beta (China Mobile) reports that after upgrading, the app forces a fresh login on every launch — the cached session is never restored.

Root cause: On cold start, HomeNotifier.build() calls getUserData() before the asynchronously-started SetupRadiance has stored the Go core. Mobile.userData() returns radiance not initialized, so build() throws with no fallback and the persisted logged-in/Pro session is never restored (checkIfUserProAndDeviceIsAdded never runs). The stored setting still reads userLoggedIn: true, yet the app looks logged-out. Reliably reproduced in China, where GFW-blocked config/auth traffic (df.iantem.io reset) widens the init window so the race is lost on every launch. Confirmed against logs: 9.1.9/9.1.11 launches on the same device succeed; the first 9.1.15 launch onward throws radiance not initialized at getUserData.

What changed: lib/features/home/provider/home_notifier.dart — build() now retries the local getUserData() read a bounded number of times (10 x 500ms) only while the failure is the transient "core not initialized" race, restoring the session once radiance comes up. Any other failure surfaces immediately with the original throw behaviour, so genuine errors are unchanged.

Test plan

• Cold-start 9.1.15 on Android with radiance init artificially delayed (slow/blocked network, e.g. block df.iantem.io) — verify the session is restored instead of showing logged-out
• Verify no added startup delay on the happy path (core already ready -> first attempt succeeds)
• Confirm genuine getUserData failures still surface (no infinite/masked retry)
• Check for regressions in refreshUser / fetchUserData (unchanged, but same provider)

Notes for reviewer

This is a Dart-side mitigation of a startup ordering race. A more complete fix would have SetupRadiance signal readiness so build() can await it rather than poll; that's a larger change spanning the platform channel and is left for follow-up. See ticket diagnosis for the full call path and the unresolved question of which radiance bump between 9.1.11 and 9.1.13 widened the window.

---

Auto-generated by /ticket-autodiagnose -> /issue-fix.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 6a854228-5355-4fb5-9a2b-81f92fc2df63

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch auto-fix/ticket-180375

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[atavism]

I don't think bounded polling is the right fix here. The 5-second retry window can still lose the race if post-upgrade setup takes longer, and matching not initialized / not ready strings couples Flutter to Go error wording.

#8915 fixes the ordering at the source: Android exposes a replayable readiness signal after setupRadiance() succeeds, and HomeNotifier waits for it before the initial getUserData() call. That removes the arbitrary timing window without retrying or masking unrelated errors, and includes a regression test for the startup ordering.

I suggest closing this in favor of #8915.