[HOLD for payment 2025-02-07] BUG: Receipt is deleted if app is killed while request is in queue

[neil-marcellini]

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

---

Version Number: v9.0.55-9
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?:
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: See the linked issue below
Expensify/Expensify Issue URL: https://github.com/Expensify/Expensify/issues/434533
Issue reported by: @neil-marcellini

Originally reported internally here

Slack conversation https://expensify.slack.com/archives/C049HHMV9SM/p1730315753190039

Action Performed:

1. Go offline
2. Submit an expense and scan a receipt with the in app camera, submit it to anyone
3. Kill the app
4. Re-open the app
5. Go back online

Expected Result:

The receipt is uploaded and scanned correctly. If it fails for some reason, then the user is able to download the receipt.

Desired Result:

Store images captured with the in app camera to a non-temporary folder in the application folder within the file system. For example, store images in a folder Receipts-Pending-Upload under the New Expensify folder.

We're still discussing in the thread linked below, but maybe after a receipt has been uploaded on the server, delete it from this folder.

Actual Result:

There is an error submitting the expense and no option to download the receipt. If the user dismisses this error then they permanently lose the receipt image.

Notes

I think this happens because we store the receipts in a /tmp/ folder which is cleared when the app is killed (E.g. file:///private/var/mobile/Containers/Data/Application/C5B31E5E-C6BD-4372-B1DF-D1326BDA7B28/tmp/9C8642AF-C0FF-44F9-988A-10B3A752B7A2.jpeg). It's a common nervous habit of iOS users to kill apps whenever they go to the home screen, so it's pretty realistic that this can happen, especially if the SequentialQueue gets a bit backed up.

More discussion in #quality.

Looks like if we upgrade react-native-vision-camera we can specify a path when taking the photo. Or we could manually move the file to our desired location, if upgrading vision camera is really difficult.

Workaround:

Try to take screen shots of the receipt images before dismissing the error and try re-uploading later. Not a very good workaround especially when users trust our app not to lose data.

Platforms:

Which of our officially supported platforms is this issue occurring on?

iOS Standalone, maybe others.

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

OfflineReceiptLoss_10-30-2024.11-48-37_1.MP4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @johncschuster

[melvin-bot]

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

[melvin-bot]

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

[ikevin127]

From taking a quick look at what happens to the RequestMoney call which was stored in the sequential queue and resumed once back online, I'm not entirely sure that the receipt is deleted from the API call, it looks like the receipt [Object] is still there and passed with the call upon returning back online when the call being made.

What I noticed instead is a 405 response from the BE regarding the RequestMoney call, mentioning that no amount was specified, which I think is what leads to the red error which if dismissed -> removes the expense entirely, giving the sense that the receipt was lose because of closing the app, when in fact the expense call failed and when dismissed, the expense goes away completely.

Note: I also noticed a Onyx merge error once the call is being made when returning back online, most likely coming from the BE response in onyx data.

I'd look into this from a BE perspective to see what happens there, if the receipt is indeed passed and why does the BE respond with error in this issue's case. I'm assuming it might have something to do with the scan being intrerupted by the user closing the app while offline, then getting back online and call being resumed from squential queue, since the BE response is error: no amount was passed.

[neil-marcellini]

Hi, thanks for taking a look @ikevin127. There's a lot more context that I forgot to add to the issue description. I'll start adding that now. I'll also work on doing some backend testing to verify that the receipt file is not received in this case. I'm having a bit of trouble getting the iOS simulator to connect to my dev environment, which is why I haven't been able to gather that info yet. However, I'm pretty sure that's what's happening.

[neil-marcellini]

The description is updated now.