Status - Status button and set status is not displayed in the settings RHP

[applause-bot]

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: v9.4.32-0
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-54982/folder/13176687/41236680/1554721226?sort=%2Bidentifier
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11/ Chrome
App Component: User Settings

Action Performed:

1. Sign in staging.new.expensify.com
2. Navigate to Account > Profile > Status
3. Set a new status

Expected Result:

Status is displayed in the account settings RHP

Actual Result:

Status button along with status set are not displayed in settings RHP

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7203796_1783601923246.bandicam_2026-07-09_15-49-37-732.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7203796

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/aa8019cd7f07e625d09cf90ed0bba1ed70321a759c438a75a1a94a7e66d058b6

[melvin-bot]

Triggered auto assignment to @flodnv (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]

🔍 Investigation Summary

Classification: Frontend bug (App) — but no App PR modifies the affected rendering path (see analysis)
Causing PR: None confirmed. Only App PR touching ProfilePage.tsx this release is #95421 - "Restore Wallet and other Account sections for agent accounts" by @NicolasBonet (Low confidence — does not touch the Status row)
Related Issues: N/A

Recommendation: NEEDS INVESTIGATION

The code that renders the Status row on the Profile settings page is byte-for-byte identical to production (9.4.31-0) — no App PR in this release changed the Status rendering, its gating, the CustomStatus pages, or the shared MenuItem/Section components. I could not tie the symptom to a code change, so I am keeping the DeployBlockerCash label and requesting more info rather than removing it.

Assigned: @NicolasBonet (PR author), @cretadn22, @yuwenmemon (approving reviewers) of #95421 — the only Profile-page change this release, for context (low confidence it is the cause).
Labels: No change. DeployBlockerCash kept (issue not shown to be non-App, and label was auto-assigned by melvin-bot, not manually removed-eligible).

📋 Detailed Analysis

Evidence

• The Status menu item is rendered from the publicOptions array in ProfilePage.tsx and mapped into MenuItemWithTopDescription rows. The Status entry renders unconditionally (it is not behind isAgentAccount, a beta, or any canUseXYZ gate).
• I diffed ProfilePage.tsx between production tag 9.4.31-0 and staging HEAD a2304e2bb7b8a6e169ebef55d10c6b9b157b3b5f (PR Restore Wallet and other Account sections for agent accounts #95421). The only changes are to the Contact Methods entry (removing isAgentAccount gating) and to the private section wrapper. The Status option block is unchanged.
• Bug is reported staging-only, web-only (Windows/Chrome, macOS/Chrome/Safari), not on mobile — a signal that usually implies a platform-specific or shared-component regression, but none is present here (there is no ProfilePage.web.tsx; a single ProfilePage.tsx serves all platforms).

Verification

• Affected file (row rendering): src/pages/settings/Profile/ProfilePage.tsx
  • Status option definition: ProfilePage.tsx#L120-L126
  • Render map: ProfilePage.tsx#L260-L277
• Status detail page (used when the row is tapped): src/pages/settings/Profile/CustomStatus/StatusPage.tsx — route SETTINGS.PROFILE.STATUS still registered at ModalStackNavigators/index.tsx#L500. Neither StatusPage.tsx nor the navigator's Status route changed this release.
• Files changed between 9.4.31-0 and HEAD in the relevant area: only ProfilePage.tsx (and Avatar-related files). Not changed this release: MenuItem.tsx, MenuItemWithTopDescription.tsx, Section/index.tsx, any CustomStatus/* page, useCurrentUserPersonalDetails, or the status field in personal-details utils.

Root Cause

Unconfirmed from App code. Since the entire Status rendering path is unchanged from production, the most likely explanations are:

1. Data/backend: currentUserPersonalDetails.status (emojiCode/text) not being returned/populated on staging, which matches "setting a status also does not display it." The row's title is emojiCode ? \${emojiCode} ${text}` : ''` — an empty status yields an empty title while the "Status" description still renders. If the description is genuinely missing too, that points to data upstream rather than this component.
2. Repro/environment specific: possibly a specific (e.g. agent) account or a staging-only data state.

What we need to proceed

• The screen recording / screenshot for this account, confirming whether the "Status" label row is missing entirely, or only the set-status value is missing.
• Whether the affected account is an agent account.
• A request_id from the OpenApp/UpdateStatus call on staging so we can confirm whether the backend returns the status field on personalDetails.

If it turns out the backend is not returning the status field for a correctly-formed request, this is a Backend bug and DeployBlockerCash should be removed in favor of DeployBlocker. Until confirmed, we keep DeployBlockerCash.