[Due for payment 2025-11-03] [$250] Gracefully handle when `OpenApp` fails

[tgolen]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Reproducible in staging?: Yes
Reproducible in production?: Yes
Logs: logs
Expensify/Expensify Issue URL:
Issue reported by: @davidcardoza
Slack conversation #quality

Action Performed:

1. Launch app
2. OpenApp API request fails with "jsonCode":404

Expected Result:

We should present some kind of message to the user to gracefully handle the failure. I don't know that there is anything they can do about it... but maybe we should also detect if multiple OpenApp calls have failed with a 404 and stop calling the API for a period of time.

I think we should probably cause an ENSURE_BUGBOT issue to be opened for it as well. That way we can tell the user "We have been notified and are looking into the problem."

cc @Expensify/design you might have some ideas on how to handle this case.
cc @mountiny

Actual Result:

Inbox is shown as empty (with a congratulatory animation). The API request spinner (bar) never goes away

Workaround:

There is no workaround

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Platforms Tested:

On which of our officially supported platforms was this issue tested:

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

Screenshots/Videos

Add any screenshot/video evidence

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021937995190940102861
• Upwork Job ID: 1937995190940102861
• Last Price Increase: 2025-10-08

Issue Owner

Current Issue Owner: @CortneyOfstad

[melvin-bot]

Triggered auto assignment to @adelekennedy (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.

[shawnborton]

What do we think the message we communicate to the user would say? We can design some kind of generic empty state for this case, but I'm mostly just curious how we position this to the user.

[shawnborton]

Especially since it seems like there might not be any action the user could take? Or can they retry loading the Inbox or something?

[dannymcclain]

Totally agree with Shawn, and definitely curious if a reload or something like that could help.

[trjExpensify]

I brought this up a while ago here as well. I think the congratulatory empty state in the Inbox is super confusing for a state of "we can't load your account properly".

It didn't really go anywhere at the time, the consensus being to focus on fixing how and why an account gets into that state in the first place. That said, some earlier ideas were to have a CTA that would effectively do the same as "Clear cache and restart" or pull down to do it etc.

[mountiny]

I think the congratulatory empty state in the Inbox is super confusing for a state of "we can't load your account properly".

It is not designed for that, but for sure using a focus mode in case they do not have any pinned chats and then go through everything unread.

That said, some earlier ideas were to have a CTA that would effectively do the same as "Clear cache and restart" or pull down to do it etc.

Yeah I am honestly a bit not sure what is the best action here as if there is some issue with OpenApp like we saw last week it will just keep failing for account like Jason so if we update the UI to ask the user to clear cache and reload it might just not lead to anything much better honestly.

But if we consider this edge case and mainly they can fix it by calling OpenApp again, then I think we can add CTA that will clear cache and restart 👍

[muttmuure]

Personally, I always liked Twitter's way of handling this case:

[dubielzyk-expensify]

Would we just reuse the standard full screen error then? (just better copy)

[mountiny]

It might be a bit abrupt as they will see the app normally but loading before we know we should show this state. At the same time they could navigate to any tab so to cover all our bases the full screen might be best solution in this case