fix(app): staging banner not showing on TestFlight builds

[beastoin]

Fixes the staging environment banner never appearing despite the app running on api.omiapi.com.

isUsingStagingApi (env.dart:34-41) was reading _instance.stagingApiUrl directly — which is always empty because STAGING_API_URL env var is not set in prod builds. The stagingApiUrl getter has a hardcoded fallback to https://api.omiapi.com/, but the banner check bypassed it. Introduced in commit 2f2b2e01d3 (Mar 16).

Fix: use the stagingApiUrl getter (with fallback) instead of the raw _instance.stagingApiUrl.

Closes part of #5949

---

by AI for @beastoin

[greptile-apps]

Greptile Summary

This PR fixes a one-line regression introduced in commit 2f2b2e01d3 where isUsingStagingApi read the raw _instance.stagingApiUrl field directly, which is always null when STAGING_API_URL is absent from the build environment (e.g. TestFlight). The fix replaces the raw field access with a call to the static stagingApiUrl getter, which carries a hardcoded fallback to https://api.omiapi.com/ — meaning the comparison is now evaluated correctly and the staging banner appears whenever apiBaseUrl resolves to that URL.

Key changes:

• Removed the three-line guard that early-returned false when _instance.stagingApiUrl was null/empty.
• The isUsingStagingApi getter now delegates to stagingApiUrl (the public getter with fallback) instead of the raw backing field, matching the design intent of that getter.

Considerations:

• If STAGING_API_URL is not set in any environment and API_BASE_URL happens to be set to https://api.omiapi.com/ in a prod build, the staging banner would appear. Based on the codebase context (api.omi.me appears to be the production host), this should not occur in practice, but is worth keeping in mind if the URL topology changes.
• The hardcoded fallback in stagingApiUrl (https://api.omiapi.com/) is now load-bearing for the banner logic; any future change to the staging host must update it.

Confidence Score: 5/5

• This PR is safe to merge — it is a minimal, targeted fix with no side effects for normal production builds.
• The change is a single-line correction that aligns isUsingStagingApi with the intended design of the stagingApiUrl getter. Production builds using api.omi.me are unaffected. The only theoretical risk (staging banner appearing unexpectedly) would require a misconfigured API_BASE_URL in a prod build, which is not a code defect in this PR.
• No files require special attention.

Important Files Changed

Filename	Overview
app/lib/env/env.dart	Removes the raw _instance.stagingApiUrl guard and replaces it with the public stagingApiUrl getter (which has a hardcoded fallback to https://api.omiapi.com/), so the staging banner now correctly appears on TestFlight builds that hit that URL even when STAGING_API_URL isn't set in the build environment.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["isUsingStagingApi called"] --> B{"apiBaseUrl == null?"}
    B -- yes --> C["return false"]
    B -- no --> D["resolve stagingApiUrl getter"]
    D --> E{"_instance.stagingApiUrl\nset in env file?"}
    E -- yes --> F["use configured value"]
    E -- no --> G["fallback: 'https://api.omiapi.com/'"]
    F --> H{"_normalizeUrl(apiBaseUrl)\n== _normalizeUrl(stagingApiUrl)?"}
    G --> H
    H -- yes --> I["return true → show staging banner"]
    H -- no --> J["return false → hide banner"]

    style C fill:#f88,stroke:#f00
    style I fill:#8f8,stroke:#0a0
    style J fill:#f88,stroke:#f00
    style G fill:#ff9,stroke:#a80

Loading

_{Reviews (1): Last reviewed commit: "fix(app): staging banner not showing whe..." | Re-trigger Greptile}