[Due for payment 2026-09-18] Crash when switching between Inbox & Spend while waiting for invited workspace chat to appear

[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: 9.4.66-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
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/71924520/folder/52649330/41237091/1717128293?sort=-identifier
Email or phone of affected tester (no customers): jsoidjnosnjionsjdosjo2@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Left Hand Navigation (LHN)

Action Performed:

1. Go to staging.new.expensify.com
2. [User A] Go to workspace settings > Members.
3. [User A] Invite User B to the workspace.
4. [User B] Quickly switch between Inbox and Spend while waiting for workspace chat to appear on LHN.

Expected Result:

App will not crash when switching between Inbox and Spend while waiting for invited workspace chat to show up.

Actual Result:

App crashes when switching between Inbox and Spend while waiting for invited workspace chat to show up.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7249182_1788361746308.8.mp4

Bug7249182_1788361827961!staging.new.expensify.com-1788361503725.txt

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @mallenexpensify

[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/59dcb2e5da817ace21adfe8fb23438bdb80bfedd380a51f4debcdf16e649f087

https://platform.applause.com/services/links/v1/external/6fc62dea887aff47f7388f225151dc95577a4eadb4216b23b11729bcf1552802

[MelvinBot]

Proposal

What is the root cause of that problem?

WorkspaceAvatar calls .toString() on an avatarID prop that is undefined. That throws during render, the error escapes to the root, and the whole app white-screens.

src/components/Avatar/WorkspaceAvatar.tsx:58

This is the confirmed throwing line, not a guess. The attached console log names main-aa1c1efc2b45656b.bundle.js:2:764701; staging still serves that exact build, and UTF-16 column 764701 in it lands on the toString token of getDefaultWorkspaceAvatarColor(y.toString()) inside the WorkspaceAvatar module, where y is the destructured avatarID prop. The stack (processRootScheduleInMicrotask → performSyncWorkOnRoot → renderRootSync → renderWithHooks) confirms it throws in the component body during a sync render, and the "navigation object hasn't been initialized yet" line right after is the tree tearing down.

Why avatarID is undefined: the only unguarded <WorkspaceAvatar> call site in the whole shipped bundle is the workspaces list row, which passes the policy ID straight through — WorkspaceTableRow.tsx:133 and :178. Every other call site coalesces with CONST.DEFAULT_NUMBER_ID.

item.policyID is just policy.id (WorkspacesListPage.tsx:146, selectors/Policy.ts:135). Rows are admitted by shouldShowPolicy, which checks type, pendingAction and role but never checks policy.id — unlike getActivePolicies, which does require !!policy.id. So the partially-populated policy_<id> record the invitee receives during the invite still produces a row, with policyID: undefined.

Why only a brand-new workspace: the crashing line is only reached on the fallback-icon branch. A workspace with an uploaded avatar has a string source and returns early at line 40. A just-joined workspace has no avatarURL, so icon is undefined and line 58 runs.

Regression history:

PR	Merged	Effect
#95050	2026-07-26	Changed getDefaultWorkspaceAvatarColor(avatarID?.toString() ?? '') to the unguarded form and made avatarID a required prop
#97465	2026-08-07	Switched WorkspaceTableRow from <Avatar> (which defaulted avatarID to CONST.DEFAULT_NUMBER_ID) to <WorkspaceAvatar> directly, dropping the last default

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

1. Restore the guard in WorkspaceAvatar — make avatarID optional and coalesce before .toString() (back to the pre-[No QA] Avatar component decomposition #95050 behaviour). This alone makes the crash impossible for every caller.
2. Guard the call site — in WorkspaceTableRow.tsx at :133 and :178, fall back to CONST.DEFAULT_NUMBER_ID so it matches every other <WorkspaceAvatar> usage.
3. Optional hardening — require !!policy.id in shouldShowPolicy (or in createWorkspaceListPoliciesSelector) so an id-less policy never reaches the workspaces list at all.

What alternative solutions did you explore?

Paths ruled out, and the one assumption I could not verify

Ruled out. I searched the LHN and Spend paths first, since the report attributes this to the LHN. Neither contains the throwing line: src/components/LHNOptionsList/**, SidebarUtils.ts, useSidebarOrderedReports, and the LHN avatar chain (OptionRow/Avatar → SubscriptAvatar/SingleAvatar → AvatarFromIcon.tsx:26) all coalesce icon.id. In the Spend path, NavigationTabBar has zero .toString() calls and the five in SearchUIUtils.ts are all guarded. The bundle offset independently excludes all of them — the nearest other .toString() in the deployed bundle is ~263 KB away.

Reachability. WorkspacesListPage is a bottom-tab screen (TabNavigator.tsx) with lazy: true, freezeOnBlur: true. On web freezeOnBlur is a no-op — that is exactly why App added its own FreezeWrapper using react-freeze. ReportsSplitNavigator and SearchFullscreenNavigator are wrapped in it; WorkspaceNavigator is not. So once the Workspaces tab has been opened, it stays mounted and keeps re-rendering on policy_ Onyx updates while the user is on Inbox or Spend. The rapid tab switching supplies the sync-lane renders that make the partially-populated policy visible.

Unverified assumption. This requires the tester to have opened the Workspaces tab at some point in that session — the repro steps don't say, and it's the one link I couldn't prove. Similarly, "policy.id is briefly absent on the invitee's record" is inferred from shouldShowPolicy omitting the check (and from the ~14 !policy?.id guards elsewhere in src/libs/), not from a runtime Onyx dump. Adding a temporary console.trace in WorkspaceAvatar when avatarID == null and re-running the Applause repro would nail both in one shot. Neither affects the fix: fix 1 is correct regardless of which caller passes undefined.

Also worth a separate look: SearchQueryUtils.ts:520 does getPersonalDetailByEmail(x)?.accountID.toString() — the optional chain stops one level early. Same latent hazard, not this crash.

💡 Suggested AI code review rule

This is a recurring, mechanically detectable pattern, so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for Expensify/App:

• Rule: CONSISTENCY-19 — Onyx record fields are possibly undefined, whatever the type says
• Condition: Flag when a value read off an Onyx record (or a selector projection of one) has a method called on it — .toString(), .split(), .length — or is passed to a required prop, without ?. or a ?? fallback. Also flag a refactor that removes an existing ?./?? guard purely because the prop type became non-optional. Onyx types describe the fully-hydrated record; partial merges land field-by-field.
• Why: Onyx types are aspirational, not runtime contracts. policy.id is typed string but ~14 sites in src/libs/ already guard !policy?.id. Dropping one such guard white-screened the app — this issue.
• Search pattern: diffs that delete ?. or ?? CONST.DEFAULT_NUMBER_ID from a line while keeping the call; and \.(toString|split|trim|toLowerCase)\( applied directly to policy\.id, report\.reportID, or \.accountID without ?..
• Offending code (❌): WorkspaceAvatar.tsx:58 and WorkspaceTableRow.tsx:133
• Fix (✅): the guarded form every other call site already uses, AvatarFromIcon.tsx:26

The full rule file, with the ❌/✅ code inline in App's coding-standards format, would go in App/.claude/skills/coding-standards/rules/. If it's worth adding, a maintainer can open it there as a draft PR.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/100204) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

---

view run · no recording available

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @linhvovan29546 (External)

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[linhvovan29546]

@MelvinBot The crash looks related to this Sentry issue. Could you please check if it’s the same issue? https://expensify.sentry.io/issues/7684111007/

[linhvovan29546]

@MelvinBot And this one as well https://expensify.sentry.io/issues/7684111007/?environment=staging&environment=production&project=4510228107427840&query=user.email%3A%EF%80%8DContains%EF%80%8Djsoidjnosnjionsjdosjo2%40gmail.com&referrer=issue-stream&sort=freq

[MelvinBot]

Almost certainly the same issue — but I couldn't open the Sentry link to confirm it myself. The Sentry MCP server needs an interactive OAuth login and didn't authenticate in this run, so I can't read issue 7684111007. Here's everything you need to decide it in about ten seconds.

(Both your links point at the same issue ID — the second just adds a user.email filter — so it's one Sentry issue, not two.)

This crash definitely does reach Sentry

The throw happens during render, so React unwinds to App's root error boundary at App.tsx:135, which calls logError.ts:10 → Sentry.captureException. A Sentry issue for this crash must exist.

Fingerprint to match against 7684111007

From the attached Applause console log:

TypeError: Cannot read properties of undefined (reading 'toString')
    at main-aa1c1efc2b45656b.bundle.js:2:764701
    at renderWithHooks
    at updateFunctionComponent
    at beginWork
    ...
    at performSyncWorkOnRoot
    at processRootScheduleInMicrotask

It's the same issue if all three hold:

1. Title is TypeError: Cannot read properties of undefined (reading 'toString').
2. The top in-app frame is WorkspaceAvatar — WorkspaceAvatar.tsx:58, getDefaultWorkspaceAvatarColor(avatarID.toString()).
3. The event carries the errorInfo extra and the NewExpensify crash caught by error boundary message, i.e. it came through the error boundary rather than a raw handler.

Check 2 is the one that matters. Cannot read properties of undefined (reading 'toString') is a generic message and Sentry groups on stack — if the top in-app frame is anything other than WorkspaceAvatar, it's a different bug that happens to share a message, and the sameness doesn't follow from the title alone.

Your second link is already good supporting evidence: it shows 7684111007 has events from jsoidjnosnjionsjdosjo2@gmail.com, the exact Applause tester on this report.

Still unfixed on main

Both parts of the proposal are unchanged as of ce33920: WorkspaceAvatar.tsx:58 still calls .toString() unguarded on a required avatarID prop, and WorkspaceTableRow.tsx:133 and :178 still pass item.policyID straight through with no CONST.DEFAULT_NUMBER_ID fallback.

If 7684111007 does point at WorkspaceAvatar, its event volume also settles the open question from my proposal — how often an id-less policy actually reaches that row — and the ?environment= breakdown would tell us whether it's staging-only or hitting production users too. Worth pasting the top frames here either way.

---

view run

[MelvinBot]

That's the same Sentry issue as your first link — ID 7684111007, just filtered to the tester's email across staging and production — so my answer above is unchanged, and I still couldn't open it. Sentry needs an interactive OAuth login that isn't available to me here.

The one check that settles it: in that filtered view, open any event and look at the top in-app frame. If it's WorkspaceAvatar.tsx:58 (getDefaultWorkspaceAvatarColor(avatarID.toString())), it's this bug. The title alone won't tell you — Cannot read properties of undefined (reading 'toString') is generic and Sentry groups on stack.

Since you've already scoped it to this tester, two things in that view are worth pasting back: the event count (how often an id-less policy actually reaches that row — the open question in my proposal) and the staging-vs-production split (whether real users are hitting it, not just Applause).

---

view run

[linhvovan29546]

MelvinBot's proposal LGTM!

🎀 👀 🎀 C+ reviewed