Tags - Hmm... it's not here page opens when going offline on the Add Tag page

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.69-3
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-27381/folder/13176676/41237293/1401520720?sort=%2Bidentifier
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 15.4.1 Safari/Chrome, iPhone 13 iOS 26.3.1
App Component: Workspace Settings

Action Performed:

1. Go to https://staging.new.expensify.com
2. Create a workspace
3. Go to More featires
4. Enable Tags
5. Go to Tags page
6. Click Add tag button
7. Press Command+D (Mac)
8. Toggle on Force offline

Expected Result:

No unexpected page should open when going offline on the Add Tag page

Actual Result:

Hmm... it's not here page opens when going offline on the Add Tag page

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Bug7148886_1778285230615.Recording__2149.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @tylerkaraszewski (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

What is the root cause of that problem?

The useEffect guard in AccessOrNotFoundWrapper.tsx:188 fails to protect against navigation when transitioning to offline.

The guard condition (pendingField && !isOffline && !isFeatureEnabled) is designed to prevent redirecting the user to the "More Features" page while a feature toggle (like enabling Tags) is still pending. However, it only protects when online (!isOffline must be true). When the user goes offline, !isOffline becomes false, the entire guard evaluates to false, and the effect proceeds to navigate away — even though the feature toggle is still pending.

The sequence is:

1. User enables Tags → optimistic data sets areTagsEnabled: true, pendingFields.areTagsEnabled: 'update'
2. If the server response for CreateWorkspace arrives before EnablePolicyTags completes, it merges the full policy with areTagsEnabled: false, overwriting the optimistic value — while pendingFields.areTagsEnabled remains set
3. While online, the guard (pendingField && !isOffline && !isFeatureEnabled) = (true && true && true) = true → early return, no navigation
4. User toggles Force Offline → isOffline becomes true, guard becomes (true && false && true) = false → navigation fires, user lands on "Hmm... it's not here"

What changes do you think we should make in order to solve the problem?

Remove the !isOffline condition from the guard at AccessOrNotFoundWrapper.tsx:188, so that the pending-field protection applies regardless of network state:

Change the guard from:
(pendingField && !isOffline && !isFeatureEnabled)
to:
(pendingField && !isFeatureEnabled)

This ensures that as long as a feature toggle is pending (optimistic update in flight), we never navigate the user away — whether they're online or offline. The isOffline dependency should also be removed from the effect's dependency array.

What alternative solutions did you explore? (Optional)

An alternative would be to add isOffline as an additional early-return condition (i.e., don't navigate at all when offline). However, that's overly broad — if someone genuinely disables a feature and then goes offline, they should still be navigated away. The targeted fix of removing !isOffline from the pending-field guard preserves the intended behavior while fixing the race condition.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.