Skip to content

104152 - Help - Talk to a human is not disabled when offline #104167

Closed

Description

@applause-bot

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.


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:

  1. Log in to staging.new.expensify.com with gmail account
  2. 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.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7287618_1792096842096.Recording__475.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7287618

Activity

  1. applause-bot commented on Oct 15, 2026

    @applause-bot
    Author

    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

  2. added
    BugSomething is broken. Auto assigns a BugZero manager.
    on Oct 15, 2026
  3. melvin-bot commented on Oct 15, 2026

    @melvin-bot

    You have been assigned to this deploy blocker because you recently merged this PR: #104152

  4. melvin-bot commented on Oct 15, 2026

    @melvin-bot

    @chiragsalian you have been assigned to this deploy blocker because you reviewed the offending PR: #104152

  5. melvin-bot commented on Oct 15, 2026

    @melvin-bot

    @jasperhuangg you have been assigned to this deploy blocker because you authored the offending PR: #104152

  6. melvin-bot commented on Oct 15, 2026

    @melvin-bot

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

  7. github-actions commented on Oct 15, 2026

    @github-actions
    Contributor

    👋 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.
  8. MelvinBot commented on Oct 15, 2026

    @MelvinBot
    Contributor

    Deploy Blocker Analysis

    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.

    Causing PRs:

    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.
    • [CP both] Show Talk to a human without the beta flag #104152's description says it "preserves the existing offline-disabled state", so disabling offline was intended. It never worked.
    • The same disabled: isOffline pattern is used in Confirmation.tsx:101.
    • 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.
    • Offending code: HelpPage.tsx:213-224

    Next Steps: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.


    view run

  9. jasperhuangg commented on Oct 15, 2026

    @jasperhuangg
    Contributor

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

BugSomething is broken. Auto assigns a BugZero manager.EngineeringHourlyKSv2

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions