[HybridApp] Receipt thumbnails are blank for a new unvalidated account sign-up

[Julesssss]

Problem

Receipt scanning appears to be totally broken for a new account sign-up

UploadReciept logs

Device:

Version: v9.0.48-0
Device: iPhone 15 Pro, iOS 18.0.1

Reproduction steps:

• Download the latest TestFlight
• Sign-up as a new user
• Submit expense > Scan
• Take a picture of your feet
• Observe the thumbnail turn blank on upload
• Submit expense > Scan
• Add a legit receipt this time
• Observe the thumbnail turn blank on upload
• Observe “receipt scanning…” indefinitely

https://github.com/user-attachments/assets/c86f5040-97f5-4cd5-808c-6fc8b1b3ec75

Solution

investigate.

From @AndrewGable :

I would assume this is it: We share auth tokens between Old and New Apps and the encrypted auth token is used to view thumbnails due to “secured receipts” project. For some reason the encrypted auth token is the one that sometimes gets out of sync.

From @mateuuszzzzz:

The good news is that migrating to NewDot login page should solve this issue for us. But it will take some time to finish it. I bet we will need to handle this bug separately. I started research some time ago and here is related draft PR

From @trjExpensify:

P.s - that flow is super rough though. Why don’t we show the magic code input on the home page for the unvalidated account? On this btw, I think we need to do something about that in the name of #convert.

• Sign-up
• Get signed in for an unvalidated session
• Sign-out
• Re-enter the email address
• See a message saying to click the validation link in an email that never came
• Click “Resend link”
• Get the magic code email
• Click the link in the email
• Get taken to mWeb where you’re told to use the same device you requested from
• After step 4, why don’t we 1) send a magic code email and 2) show the magic code input screen? I’m basically stuck at this point.

[Julesssss]

Just noting that this issue wil not block HybridApp release 9.0.47.4 as this is an existing authentication issue

[mateuuszzzzz]

FYI: Here's the draft PR where I was investigating this issue https://github.com/Expensify/Mobile-Expensify/pull/13144

[mateuuszzzzz]

I merged the latest main branches to find potential problems, and it turns out that the app sometimes crashes during Sign Up. I'm going to investigate this.

[mateuuszzzzz]

Hi, I have an update. It seems like we don’t return the encryptedAuthToken to the old app anymore, which is causing the current PR to break. We’re having a discussion about the next steps for the PR

[mateuuszzzzz]

Hi, I have a new update after another round of investigation.

I tried to implement another approach which was described here. Unfortunately, there are some issues with authentication on NewDot side with credentials generated on OldDot side (it's quite surprising, because It was working in the past 🤔).

I get the following error when I try to re-authenticate:

{"response": {"jsonCode": 404, "message": "404 No passwordless infinite login found.", "onyxData": [], "requestID": "8d4903949ac6b197-WAW"}

My guess is that we cannot make authentication request with HybridApp's partnerName (I compared how it behaves with NewDot partnerName and I did not encounter this issue).

I think we need someone from Expensify to look into this as it seems like backend issue.

Alternatively, we could switch to using NewDot's partnerName in HybridApp, but I'm not sure what impact that might have on the existing backend logic.

[AndrewGable]

@jasperhuangg - I think you were looking into this specific case on the backend, right?

[jasperhuangg]

@AndrewGable, I don’t think the issue is related to partnerName. Both the PARTNER_ANDROID and PARTNER_IPHONE are being considered in this condition, which must pass before reaching the logic that throws the exception.

The problem @mateuuszzzzz is encountering seems to be because we aren’t creating a temporary login for the user when they sign into HybridApp, unlike what we do for NewDot, which makes this check fail. When a temporary login is created, an NVP is also set, which is checked in situations like this.

This issue is similar to this one because both involve differences in the HybridApp sign-in flow compared to NewDot. However, the root cause in each case is different, as different parts of the sign-in flow are inconsistent. To clarify, the issue I'm assigned to is caused by the partnerNames being inconsistent between HybridApp and NewDot.

[Julesssss]

I hope to have more time to help triage the backend issues soon.