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
[$250] "Uh-oh, something went wrong!" when trying to access New Expensify or the dedicated chat with Concierge #84087
Version Number: v9.3.27-8 Reproducible in staging?: Needs Reproduction (Unable to reproduce) Reproducible in production?: Needs Reproduction If this was caught during regression testing, add the test name, ID and link from BrowserStack: Email or phone of affected tester (no customers): Logs:https://stackoverflow.com/c/expensify/questions/4856 Expensify/Expensify Issue URL: Issue reported by:@abbagail Slack conversation (hyperlinked to channel name): #Expensify Bugs
Action Performed:
Login In Classic, click "support."
Select "Concierge"
Get redirected to New Expensify
Expected Result:
New Expensify Load without issues.
Actual Result:
Page takes a few seconds to load, but fails to load and gets "Uh-Oh, something went wrong." (App crashes)
Workaround:
Unknown
Platforms:
Select the officially supported platforms where the issue was reproduced:
Please re-state the problem that we are trying to solve in this issue.
When users click "Support" > "Concierge" in Classic Expensify and get redirected to New Expensify, the app crashes after a few seconds of loading, showing the "Uh-Oh, something went wrong!" error page (the GenericErrorPage rendered by the app's top-level ErrorBoundary). This affects web platforms (Windows Chrome, MacOS Chrome/Safari) on version v9.3.27-8.
What is the root cause of that problem?
Note: Without access to the actual Sentry error logs / stack trace referenced in the issue, the following is a high-confidence hypothesis based on code analysis. The actual error message from the ErrorBoundary would confirm the exact crash point.
The most likely root cause is an unhandled error during the report rendering flow after navigating from Classic to the Concierge chat. The crash flow is:
Classic redirects to new.expensify.com/concierge (or via /transition?exitTo=/concierge)
ConciergePage (src/pages/ConciergePage.tsx:29-43) mounts, waits for data, then calls navigateToConciergeChat() which navigates to ReportScreen
After a few seconds (while data loads and derived values compute), a re-render triggers an uncaught error that the ErrorBoundary catches
There are several potential crash vectors identified in the code:
Primary suspect — VISIBLE_REPORT_ACTIONS derived value (PR #81280):
This derived value (src/libs/actions/OnyxDerived/configs/visibleReportActions.ts) computes visibility for ALL report actions across ALL reports with no try-catch error handling in createOnyxDerivedValueConfig. If any computation throws, it propagates to the component.
ReportActionsView uses actions.pop()! with a non-null assertion (src/pages/inbox/report/ReportActionsView.tsx:210) — if the actions array is empty, this returns undefined and accessing .pendingAction on line 212 throws a TypeError
Contributing factor — v9.3.27 staging instability:
The v9.3.27 staging cycle had 5 PRs reverted via cherry-picks, an unusually high number. Notably, the revert of useLoadReportActions changes (v9.3.27-3) directly affects how report actions load for ReportScreen, and the revert of InteractionManager migration (v9.3.27-2) touched Navigation.ts and Report/index.ts. These reverts may create subtle data-timing inconsistencies with PR #81280's derived value changes.
What changes do you think we should make in order to solve the problem?
Step 1: Get the actual error from logs — The Sentry/error logs referenced in the issue (internal SO link) should contain the exact JavaScript error message and component stack trace from the ErrorBoundary. This will pinpoint the exact crash location among the candidates identified above.
Step 2: Based on the most likely crash points, the fix should include:
Add error handling to the VISIBLE_REPORT_ACTIONS derived value computation in src/libs/actions/OnyxDerived/configs/visibleReportActions.ts — wrap the compute function in a try-catch to prevent computation errors from propagating to components.
Remove the non-null assertionactions.pop()! in src/pages/inbox/report/ReportActionsView.tsx:210 and add a null check before accessing createdAction.pendingAction on the next line.
Add defensive null checks in ReportScreen for the derived value data paths that could be undefined during initial load.
What alternative solutions did you explore? (Optional)
Reverting PR Report Actions Derived Value #81280 entirely would likely fix the crash but would remove the performance optimization the derived value provides. A targeted fix (error handling + null checks) is preferable.
changed the title [-]"Uh-oh, something went wrong!" when trying to access New Expensify or the dedicated chat with Concierge[/-][+][$250] "Uh-oh, something went wrong!" when trying to access New Expensify or the dedicated chat with Concierge[/+]on Mar 3, 2026
Hi @aimane-chnaif — apologies for the delayed response! To be transparent: our proposal was based on code analysis rather than direct reproduction, so I don't have a screen recording to share. The original crash was reported on v9.3.27-8 and the KI retests haven't been able to reproduce it since, which suggests it may have been resolved in a later patch or is environment-specific.
Given that context, if it would be useful, I'm happy to reframe our proposal as a defensive hardening PR (the try-catch around the derived value computation and the non-null assertion fix in ReportActionsView are valid defensive improvements regardless of exact reproduction). Or if the issue is best closed given the reproduction difficulty, I completely understand — just let me know how you'd like to proceed!
Hi @aimane-chnaif and @stephanieelliott — just wanted to check in one more time. It looks like the issue has been eroding and KI retests haven't been able to reproduce the crash, so I completely understand if the priority has shifted.
Our offer from April 9th still stands: happy to submit a defensive hardening PR (the try-catch around the derived value computation and the non-null assertion fix in ReportActionsView) as a proactive improvement, or to close the issue if reproduction isn't feasible. Whatever direction works best for the team — just let us know and we'll move accordingly!
Activity
melvin-bot commentedon Mar 3, 2026
Triggered auto assignment to @stephanieelliott (
Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.MelvinBot commentedon Mar 3, 2026
Proposal
Please re-state the problem that we are trying to solve in this issue.
When users click "Support" > "Concierge" in Classic Expensify and get redirected to New Expensify, the app crashes after a few seconds of loading, showing the "Uh-Oh, something went wrong!" error page (the
GenericErrorPagerendered by the app's top-levelErrorBoundary). This affects web platforms (Windows Chrome, MacOS Chrome/Safari) on version v9.3.27-8.What is the root cause of that problem?
Note: Without access to the actual Sentry error logs / stack trace referenced in the issue, the following is a high-confidence hypothesis based on code analysis. The actual error message from the ErrorBoundary would confirm the exact crash point.
The most likely root cause is an unhandled error during the report rendering flow after navigating from Classic to the Concierge chat. The crash flow is:
new.expensify.com/concierge(or via/transition?exitTo=/concierge)ConciergePage(src/pages/ConciergePage.tsx:29-43) mounts, waits for data, then callsnavigateToConciergeChat()which navigates toReportScreenReportScreenrenders and subscribes toONYXKEYS.DERIVED.VISIBLE_REPORT_ACTIONSviauseOnyx(src/pages/inbox/ReportScreen.tsx)ErrorBoundarycatchesThere are several potential crash vectors identified in the code:
Primary suspect —
VISIBLE_REPORT_ACTIONSderived value (PR #81280):src/libs/actions/OnyxDerived/configs/visibleReportActions.ts) computes visibility for ALL report actions across ALL reports with no try-catch error handling increateOnyxDerivedValueConfig. If any computation throws, it propagates to the component.git logshows 3 reverts touching this file). PR [CP Staging] Fix LHN system message preview not matching report content #83742 explicitly acknowledges it caused a regression.Secondary crash vectors:
ReportActionsViewusesactions.pop()!with a non-null assertion (src/pages/inbox/report/ReportActionsView.tsx:210) — if theactionsarray is empty, this returnsundefinedand accessing.pendingActionon line 212 throws aTypeErrorReportActionComposehas explicitthrow new Error(...)statements (src/pages/inbox/report/ReportActionCompose/ReportActionCompose.tsx:310-316,474-482) ifcomposerRef.clearWorkletis not set when the composer initializesConciergeThinkingMessagecallsParser.replace()insideRenderHTML(src/pages/home/report/ConciergeThinkingMessage.tsx:199) — malformed reasoning data could cause a render crashContributing factor — v9.3.27 staging instability:
The v9.3.27 staging cycle had 5 PRs reverted via cherry-picks, an unusually high number. Notably, the revert of
useLoadReportActionschanges (v9.3.27-3) directly affects how report actions load forReportScreen, and the revert of InteractionManager migration (v9.3.27-2) touched Navigation.ts and Report/index.ts. These reverts may create subtle data-timing inconsistencies with PR #81280's derived value changes.What changes do you think we should make in order to solve the problem?
Step 1: Get the actual error from logs — The Sentry/error logs referenced in the issue (internal SO link) should contain the exact JavaScript error message and component stack trace from the
ErrorBoundary. This will pinpoint the exact crash location among the candidates identified above.Step 2: Based on the most likely crash points, the fix should include:
Add error handling to the
VISIBLE_REPORT_ACTIONSderived value computation insrc/libs/actions/OnyxDerived/configs/visibleReportActions.ts— wrap the compute function in a try-catch to prevent computation errors from propagating to components.Remove the non-null assertion
actions.pop()!insrc/pages/inbox/report/ReportActionsView.tsx:210and add a null check before accessingcreatedAction.pendingActionon the next line.Add defensive null checks in
ReportScreenfor the derived value data paths that could be undefined during initial load.What alternative solutions did you explore? (Optional)
Next Steps for Contributor+ team: Reply with
@MelvinBot implement thisto create a draft PR, or@MelvinBot <your feedback>to refine this analysis.melvin-bot commentedon Mar 3, 2026
Triggered auto assignment to Contributor-plus team member for initial proposal review - @aimane-chnaif (
External)[-]"Uh-oh, something went wrong!" when trying to access New Expensify or the dedicated chat with Concierge[/-][+][$250] "Uh-oh, something went wrong!" when trying to access New Expensify or the dedicated chat with Concierge[/+]melvin-bot commentedon Mar 3, 2026
Job added to Upwork: https://www.upwork.com/jobs/~022028954940716757609
melvin-bot commentedon Mar 9, 2026
@aimane-chnaif Eep! 4 days overdue now. Issues have feelings too...
melvin-bot commentedon Mar 9, 2026
@aimane-chnaif Eep! 4 days overdue now. Issues have feelings too...
34 remaining items
melvin-bot commentedon Apr 7, 2026
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸
melvin-bot commentedon Apr 7, 2026
@aimane-chnaif 6 days overdue. This is scarier than being forced to listen to Vogon poetry!
melvin-bot commentedon Apr 9, 2026
@aimane-chnaif 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!
ProjectNOVACo commentedon Apr 9, 2026
Hi @aimane-chnaif — apologies for the delayed response! To be transparent: our proposal was based on code analysis rather than direct reproduction, so I don't have a screen recording to share. The original crash was reported on v9.3.27-8 and the KI retests haven't been able to reproduce it since, which suggests it may have been resolved in a later patch or is environment-specific.
Given that context, if it would be useful, I'm happy to reframe our proposal as a defensive hardening PR (the try-catch around the derived value computation and the non-null assertion fix in ReportActionsView are valid defensive improvements regardless of exact reproduction). Or if the issue is best closed given the reproduction difficulty, I completely understand — just let me know how you'd like to proceed!
mvtglobally commentedon Apr 11, 2026
Issue not reproducible during KI retests. (Fourth week)
melvin-bot commentedon Apr 13, 2026
@aimane-chnaif 12 days overdue. Walking. Toward. The. Light...
melvin-bot commentedon Apr 14, 2026
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸
melvin-bot commentedon Apr 16, 2026
This issue has not been updated in over 14 days. @stephanieelliott, @aimane-chnaif eroding to Weekly issue.
ProjectNOVACo commentedon Apr 17, 2026
Hi @aimane-chnaif and @stephanieelliott — just wanted to check in one more time. It looks like the issue has been eroding and KI retests haven't been able to reproduce the crash, so I completely understand if the priority has shifted.
Our offer from April 9th still stands: happy to submit a defensive hardening PR (the
try-catcharound the derived value computation and the non-null assertion fix inReportActionsView) as a proactive improvement, or to close the issue if reproduction isn't feasible. Whatever direction works best for the team — just let us know and we'll move accordingly!mvtglobally commentedon Apr 18, 2026
Issue not reproducible during KI retests. (Fifth week) Closing, please reopen if needed