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
[Tracking] Ensure any error page is recoverable and logs necessary info for more debugging #69850
Coming from this thread, there are some full-screen error pages that might not have an easy way to recover for the user (or none). These pages might be rare for the user to run into, but they can still happen.
Let's:
Map the places that show error pages, but they are not recoverable?
Then work with design team and product team to add ways to recover the app from that state
Add many more logs so we can create issues to investigate when this happens and that we have more idea for why this happened
That means try to identify places that precede showing this page and add logs there so we can better see why
By non-recoverable, I mean a situation where the loading indicator takes up the full space, and there are no components available that could trigger a back action in the navigation.
According to this Slack conversation, we could come up with a smart way to measure when loading indicators remain visible for too long and log the root cause (e.g., which props or states in the components are responsible for that). It could be handled directly by FullScreenLoadingIndicator.
I’m also thinking about the inconsistency in the codebase, where we sometimes use ActivityIndicator and other times FullScreenLoadingIndicator. Ideally, it would be best to have a single component responsible for this. cc: @mountiny
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!
Activity
melvin-bot commentedon Sep 4, 2025
Triggered auto assignment to @greg-schroeder (
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.mateuuszzzzz commentedon Sep 5, 2025
Hi, I searched the codebase to find non-recoverable paths. Here's the results:
List of component that use
ActivityIndicatordirectly and are non-recoverable if infinite loading occurs:https://github.com/Expensify/App/blob/main/src/pages/workspace/expensifyCard/WorkspaceExpensifyCardPage.tsx
https://github.com/Expensify/App/blob/main/src/pages/workspace/receiptPartners/WorkspaceReceiptPartnersPage.tsx
https://github.com/Expensify/App/blob/main/src/pages/workspace/companyCards/WorkspaceCompanyCardsPage.tsx
https://github.com/Expensify/App/blob/main/src/pages/iou/request/step/IOURequestStepScan/index.native.tsx
https://github.com/Expensify/App/blob/main/src/pages/iou/request/step/IOURequestStepScan/index.tsx
https://github.com/Expensify/App/blob/main/src/pages/signin/ThirdPartySignInPage.tsx
List of components that use our
FullScreenLoadingIndicatorand are non-recoverable if infinite loading occurs:https://github.com/Expensify/App/blob/main/src/pages/workspace/AccessOrNotFoundWrapper.tsx
https://github.com/Expensify/App/blob/main/src/pages/iou/request/step/IOURequestStepConfirmation.tsx
https://github.com/Expensify/App/blob/main/src/pages/TransactionMerge/DetailsReviewPage.tsx
https://github.com/Expensify/App/blob/main/src/pages/TransactionDuplicate/Confirmation.tsx
https://github.com/Expensify/App/blob/main/src/pages/Search/SearchAdvancedFiltersPage/SearchFiltersStatusPage.tsx
https://github.com/Expensify/App/blob/main/src/pages/ReimbursementAccount/ReimbursementAccountPage.tsx
https://github.com/Expensify/App/blob/main/src/pages/LogInWithShortLivedAuthTokenPage.tsx
https://github.com/Expensify/App/blob/main/src/libs/Navigation/AppNavigator/AuthScreens.tsx
https://github.com/Expensify/App/blob/main/src/pages/iou/request/step/withWritableReportOrNotFound.tsx
https://github.com/Expensify/App/blob/main/src/pages/home/report/withReportOrNotFound.tsx
https://github.com/Expensify/App/blob/main/src/pages/LogOutPreviousUserPage.tsx
By non-recoverable, I mean a situation where the loading indicator takes up the full space, and there are no components available that could trigger a back action in the navigation.
mateuuszzzzz commentedon Sep 5, 2025
According to this Slack conversation, we could come up with a smart way to measure when loading indicators remain visible for too long and log the root cause (e.g., which props or states in the components are responsible for that). It could be handled directly by
FullScreenLoadingIndicator.I’m also thinking about the inconsistency in the codebase, where we sometimes use
ActivityIndicatorand other timesFullScreenLoadingIndicator. Ideally, it would be best to have a single component responsible for this. cc: @mountinymateuuszzzzz commentedon Sep 5, 2025
I’ll be OOO from the 8th to the 12th of September, @blazejkustra will be taking over this issue.
Valforte commentedon Sep 8, 2025
Not overdue
270 remaining items
Julesssss commentedon Aug 24, 2026
Final component refactor complete, just awaiting deployment to prod and we can make the flip!
melvin-bot commentedon Aug 27, 2026
This issue has not been updated in over 15 days. @shawnborton, @Julesssss, @Valforte, @blazejkustra, @mateuuszzzzz, @situchan eroding to Monthly issue.
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!
Julesssss commentedon Aug 28, 2026
Final PR deployed to prod, we can now switch to Go Back button default to true. It's in progress here.
melvin-bot commentedon Sep 21, 2026
This issue has not been updated in over 15 days. @shawnborton, @Julesssss, @Valforte, @blazejkustra, @mateuuszzzzz, @situchan eroding to Monthly issue.
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!
Julesssss commentedon Sep 21, 2026
PR in review, bumping it here.
Julesssss commentedon Oct 21, 2026
Project complete! Thanks all
Handling payment for the last few issues here.