Chat - Compose box not displayed after logging in via chat link

[mitarachim]

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.62-5
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-22587/folder/13176964/41237742/1371131085
Email or phone of affected tester (no customers): applausetester+abr2hb@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Android/IOS
App Component: Other

Action Performed:

1. Log in in the app
2. Copy a conversation/chat link in the note
3. Log out from the app.
4. Open a conversation/chat link in step 2.
5. Log in to the app with same account in step 1 .
6. Observe the chat screen.

Expected Result:

The compose box should be visible, allowing the user to send messages after logging in via the chat link.

Actual Result:

The compose box is not displayed after logging in via the chat link.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7139458_1777311013536.WhatsApp_Video_2026-04-27_at_19.17.49.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @deetergp (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.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #88733 - "[CP Staging] fix Deeplink - App is stuck on splash screen when navigating to a public room as anon user" by @situchan (Medium confidence)
Related Issues: #88653, #88545

Recommendation: NEEDS INVESTIGATION

PR #88733 is the most likely candidate, but the exact mechanism by which it suppresses the compose box after login is not conclusively traced. The PR author and reviewers should verify whether reverting or patching #88733 resolves the issue.

Assigned: @situchan (PR author), @ikevin127 @mollfpr (approving reviewers) from highest-confidence causing PR only
Labels: Both DeployBlockerCash and DeployBlocker are kept — this is a staging-only regression on a frontend component (App repo), so DeployBlockerCash should remain. DeployBlocker label was already present and is kept pending clarification.

Detailed Analysis

Evidence

Bug description: After logging in via a chat link on Android/iOS native apps, the compose box is not displayed. The user lands on the correct report screen and can see messages, but cannot compose new ones.

Version affected: 9.3.62-5 (staging only, not reproducible in production 9.3.61-x).

Primary suspect — PR #88733: This cherry-pick modifies src/DeepLinkHandler.tsx in two ways:

1. Adds allReports / allReportsMetadata to the Onyx loading check:

   // Before:
   if (isLoadingOnyxValue(sessionMetadata, isSelfTourViewedMetadata)) { return; }
   
   // After:
   if (isLoadingOnyxValue(allReportsMetadata, sessionMetadata, conciergeReportIDMetadata,
                          introSelectedMetadata, isSelfTourViewedMetadata, betasMetadata)) {
       return;
   }
   

2. Adds allReportsMetadata.status (and four other new metadata statuses) to the useEffect dependency array.

Why this matters for the login-via-link flow: Before PR #88733, the DeepLinkHandler effect ran when session and self-tour data were ready. After PR #88733, the effect also re-runs whenever allReportsMetadata.status changes. When a user logs in, reports begin loading — allReportsMetadata.status transitions from "not loaded" → "loading" → "loaded". Each transition re-runs the effect, calling Linking.getInitialURL() and potentially openReportFromDeepLink again.

Critically, PR #88733 does NOT include the initialUrlProcessed guard that was added later in PR #86660. Without that guard, openReportFromDeepLink can be called multiple times after the initial URL has already been processed, creating a race condition in the navigation and post-login state setup.

Compose box mechanics: On mobile (isSmallScreenWidth = true), ReportFooter renders the compose box only when !shouldHideComposer && shouldShowComposeInput. The shouldShowComposeInput Onyx key defaults to false in ReportFooter. It is set to true by ReportFetchHandler on mount (InteractionManager.runAfterInteractions). If the re-triggered deep link navigation causes a second navigation event that interrupts or races with ReportFetchHandler's mount lifecycle, the setShouldShowComposeInput(true) call could be cancelled (the interactionTask.cancel() in the cleanup) before it fires.

Relationship to PR #86660: The later main-branch PR #86660 adds comprehensive fixes to DeepLinkHandler.tsx including an initialUrlProcessed ref guard, a Promise.race with timeout (to handle HybridApp bridge timeouts), and a safety-net useEffect for authenticated users. These fixes address the same class of re-invocation issues. PR #88733 (the cherry-pick) only includes the allReportsMetadata change without the protective guards.

Verification

Affected file: src/DeepLinkHandler.tsx — confirmed modified by PR #88733.

Files relevant to compose box:

• src/pages/inbox/report/ReportFooter.tsx — controls compose box rendering based on shouldShowComposeInput and canPerformWriteAction
• src/pages/inbox/ReportFetchHandler.tsx — sets shouldShowComposeInput(true) on mount
• src/libs/actions/Composer.ts — setShouldShowComposeInput implementation
• src/ONYXKEYS.ts — SHOULD_SHOW_COMPOSE_INPUT key definition

Chronological order confirms PR #88733 is in the 9.3.62-5 build (entry 149 in the StagingDeployCash chronological list, before entry 163 which is the 9.3.62-5 submodule update).

Root Cause

The DeepLinkHandler effect, with allReportsMetadata.status added to its dependency array but without an initialUrlProcessed guard, re-invokes openReportFromDeepLink multiple times as reports load after login. This likely creates a race condition where a second navigation event fires while ReportFetchHandler is setting up, causing the InteractionManager.runAfterInteractions task that calls setShouldShowComposeInput(true) to be cancelled by the cleanup function before it executes. The compose box then renders with shouldShowComposeInput = false and is hidden on mobile.

The complete fix (including the initialUrlProcessed guard and Promise.race timeout) exists in PR #86660 on main but was not cherry-picked to staging alongside PR #88733.

Recommended action: Either revert PR #88733 from staging, or cherry-pick the additional protections from PR #86660 (initialUrlProcessed guard + cancellation logic) into a new staging CP. The PR author @situchan and reviewer @ikevin127 are best positioned to advise on the preferred approach.