You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
104152 - Help - Talk to a human is not disabled when offline #104167
Version Number: v9.5.10-1 Reproducible in staging?: Yes Reproducible in production?: N/A - new feature, doesn't exist in prod If this was caught during regression testing, add the test name, ID and link from BrowserStack:#104152 Email or phone of affected tester (no customers): N/A Issue reported by: Applause Internal Team Bug source: Pull Request QA execution Device used: Windows 11 / Chrome App Component: User Settings
Action Performed:
Log in to staging.new.expensify.com with gmail account
Disconnect from the network and open Account > Help.
Expected Result:
“Talk to a human” remains visible and is disabled while offline.
Actual Result:
“Talk to a human” remains visible and is not disabled while offline.
👋 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:
Identify the pull request that introduced this issue and revert it.
Root cause: One wrong prop name. talkToAHumanItem sets isDisabled: isOffline at HelpPage.tsx:220. MenuItemList only reads disabled (MenuItemList.tsx:104-105), so the flag is silently dropped. Offline, the item is not greyed out and stays tappable.
Recommended fix: Roll forward, don't revert.
- isDisabled: isOffline,+ disabled: isOffline,
MenuItemList then greys it out through shouldGreyOutWhenDisabled. Optionally, add satisfies MenuItemWithLink to the item so TypeScript catches wrong prop names.
Blocker impact: Low. It only affects offline use. #104152 was already cherry-picked to production, so holding staging won't keep it out of prod. A revert would hide "Talk to a human" again without fixing beta users.
Investigation details
MenuItemProps defines disabled?: boolean (MenuItem.tsx:212-213). isDisabled isn't a MenuItem prop.
TypeScript missed it because the object is stored in an untyped const before going into the array, which skips the unknown-property check.
I verified this by reading the code. I did not reproduce it in the app.
💡 Suggested AI code review rule
Proposed for Expensify/App (.claude/skills/app-coding-standards):
Rule: Type MenuItemList item configs.
Condition: Flag item objects built in a separate variable and passed to <MenuItemList menuItems={...}> without : MenuItemWithLink or satisfies MenuItemWithLink, especially any isDisabled: key (the prop is disabled).
Why: Untyped variables skip TypeScript's unknown-property check, so wrong prop names are silently dropped at runtime.
Search pattern:isDisabled: in files that render <MenuItemList.
yeah not a concern for now, if someone tries to click talk to a human, nothing will happen while they're offline, which I feel people should expect for a feature like this
Activity
applause-bot commentedon Oct 15, 2026
While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/3c779df5fbbc41b2973e22bf097d577da84742ad0c62a3703818b696c9737a61
melvin-bot commentedon Oct 15, 2026
You have been assigned to this deploy blocker because you recently merged this PR: #104152
melvin-bot commentedon Oct 15, 2026
@chiragsalian you have been assigned to this deploy blocker because you reviewed the offending PR: #104152
melvin-bot commentedon Oct 15, 2026
@jasperhuangg you have been assigned to this deploy blocker because you authored the offending PR: #104152
melvin-bot commentedon Oct 15, 2026
💬 A slack conversation has been started in #expensify-open-source
github-actions commentedon Oct 15, 2026
👋 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:
MelvinBot commentedon Oct 15, 2026
Deploy Blocker Analysis
Root cause: One wrong prop name.
talkToAHumanItemsetsisDisabled: isOfflineatHelpPage.tsx:220.MenuItemListonly readsdisabled(MenuItemList.tsx:104-105), so the flag is silently dropped. Offline, the item is not greyed out and stays tappable.Recommended fix: Roll forward, don't revert.
MenuItemListthen greys it out throughshouldGreyOutWhenDisabled. Optionally, addsatisfies MenuItemWithLinkto the item so TypeScript catches wrong prop names.Causing PRs:
isDisabledline. Beta users have had this bug in production since then.Blocker impact: Low. It only affects offline use. #104152 was already cherry-picked to production, so holding staging won't keep it out of prod. A revert would hide "Talk to a human" again without fixing beta users.
Investigation details
MenuItemPropsdefinesdisabled?: boolean(MenuItem.tsx:212-213).isDisabledisn't aMenuItemprop.constbefore going into the array, which skips the unknown-property check.disabled: isOfflinepattern is used inConfirmation.tsx:101.💡 Suggested AI code review rule
Proposed for
Expensify/App(.claude/skills/app-coding-standards):MenuItemListitem configs.<MenuItemList menuItems={...}>without: MenuItemWithLinkorsatisfies MenuItemWithLink, especially anyisDisabled:key (the prop isdisabled).isDisabled:in files that render<MenuItemList.HelpPage.tsx:213-224Next Steps: Reply with
@MelvinBot implement thisto create a draft PR, or@MelvinBot <your feedback>to refine this analysis.view run
jasperhuangg commentedon Oct 15, 2026
yeah not a concern for now, if someone tries to click talk to a human, nothing will happen while they're offline, which I feel people should expect for a feature like this