Unable to login with non-existing account that owes money

[izarutskaya]

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: 9.0.6-0
Reproducible in staging?: Y
Reproducible in production?: Y
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team

Action Performed:

Precondition:
User B has no account yet

Steps:

1. User A with gmail account go to FAB> Submit expense> Add User B email address> Complete the submit flow
2. Wait for a minute
3. Repeat step 1 to submit a second IOU to user B
4. As User B go to staging.new.expensify.com> Type email address and click Continue

Expected Result:

User B should be able to login

Actual Result:

Unable to login with non-existing account that owes money. "Cannot get account details, please try again or contact concierge@expensify.com"
error message is displayed on login page

Workaround:

Unknown

Platforms:

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

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6538444_1720651977684.Recording__3476.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~017518e8ff7a1d7f72
• Upwork Job ID: 1811408479840104416
• Last Price Increase: 2024-07-18

Issue Owner

Current Issue Owner: @mkhutornyi

[melvin-bot]

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

[joekaufmanexpensify]

I can reproduce this, but only specifically when submitting two IOUs to someone hasn't created an account yet. If I only submit one, I have no problem logging into the new account.

[joekaufmanexpensify]

That said, this is a pretty bad bug for a core flow, so makes sense to me to fix now.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~017518e8ff7a1d7f72

[melvin-bot]

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

[mkhutornyi]

@kabeer95 Please read through contributing guideline and follow proposal template. Thanks

[kabeer95]

Problem Statement: The problem we are trying to solve is that when a user attempts to log in with a non-existing account that owes money, the system does not handle the situation correctly, leading to a poor user experience.

Root Cause: The root cause of this problem is that the current login system does not have a mechanism to detect and handle cases where a user attempts to log in with a non-existing account that owes money. This lack of error handling and recovery flow leads to a poor user experience and potential frustration.

Proposed Solution: To solve this problem, I propose the following changes:

Implement robust error handling to detect when a user attempts to log in with a non-existing account that owes money.
Display clear and concise error messaging to the user, indicating that the account does not exist or that there is an outstanding balance.
Redirect the user to a recovery flow, where they can recover their account or resolve the outstanding balance.
Alternative Solutions Explored:

Soft Delete: Instead of completely removing the account, we could implement a soft delete mechanism that marks the account as inactive but still retains the account information. This would allow users to recover their account and resolve the outstanding balance.
Account Lookup: We could implement an account lookup feature that allows users to search for their account and recover it if it exists. This would provide an additional recovery path for users who have forgotten their login credentials.
Grace Period: We could introduce a grace period for accounts with outstanding balances, allowing users to log in and resolve the balance within a certain timeframe before the account is marked as non-existent.
These alternative solutions were explored, but the proposed solution was deemed the most effective and efficient way to solve the problem.

[joekaufmanexpensify]

Still pending proposals

[jaydamani]

The request for new account with IOU and without IOU looks same. So could this be a back-end issue?

Request for user with IOU (error):

email: xxxxx@proton.me
useNewBeginSignIn: true
apiRequestType: read
referer: ecash
platform: web
api_setCookie: false
isFromDevEnv: false
appversion: 9.0.6-2
clientUpdateID: -1

Response:

{
    "code": 666,
    "jsonCode": 666,
    "type": "Expensify\\Libs\\Error\\ExpError",
    "UUID": "9882CD0B-BC6B-46E8-951D-A633A1678314",
    "message": "Cannot get account details, please try again or contact concierge@expensify.com",
    "title": "",
    "data": {
        "onyxData": [
            {
                "onyxMethod": "merge",
                "key": "account",
                "value": {
                    "errors": {
                        "1720803445531455": "Cannot get account details, please try again or contact concierge@expensify.com"
                    }
                }
            }
        ]
    },
    "htmlMessage": "",
    "onyxData": [
        {
            "onyxMethod": "merge",
            "key": "account",
            "value": {
                "errors": {
                    "1720803445531455": "Cannot get account details, please try again or contact concierge@expensify.com"
                }
            }
        }
    ],
    "requestID": "8a22927d3db1032e-AMD"
}

Request without IOU (no error):

email: xxxxxxx+aslfdk@proton.me
useNewBeginSignIn: true
apiRequestType: read
referer: ecash
platform: web
api_setCookie: false
isFromDevEnv: false
appversion: 9.0.6-2
clientUpdateID: -1

Response:

{
    "onyxData": [
        {
            "onyxMethod": "merge",
            "key": "credentials",
            "value": {
                "login": "xxxxxx+aslfdk@proton.me"
            }
        },
        {
            "onyxMethod": "merge",
            "key": "account",
            "value": {
                "validated": false,
                "primaryLogin": "",
                "accountExists": false,
                "domainControlled": false
            }
        }
    ],
    "jsonCode": 200,
    "requestID": "8a2292e37dd8032e-AMD"
}

Also noticed that the Pay button in the email send to user without account does not work, the sign-in request fails with error: "402 Invalid request, this command shouldn't get called for open accounts"

[melvin-bot]

📣 @jaydamani! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[jaydamani]

Contributor details
Your Expensify account email: jaydamani567@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01334afe3f5f15353e?mp_source=share

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[joekaufmanexpensify]

@mkhutornyi, what do you think? Do you agree this could be a backend issue?

[melvin-bot]

@joekaufmanexpensify, @mkhutornyi Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[mkhutornyi]

checking...

[mkhutornyi]

I am not able to reproduce.
Instead there's another bug: successfully logged in but shows not found page (url is /r)

[joekaufmanexpensify]

Hmm, okay. I will try and reproduce again today

[joekaufmanexpensify]

@mkhutornyi did you specifically try and submit two IOUs to the account that did not exist? When I did that the other day, and again this morning I can still reproduce.

2024-07-17_10-30-03.mp4

[joekaufmanexpensify]

Updated repro steps to clarify you need yo submit two IOUs

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[mkhutornyi]

Not able to test this. Money request flow from FAB button is broken at the moment.

(bug report: https://expensify.slack.com/archives/C049HHMV9SM/p1721328491853809)

Screen.Recording.2024-07-18.at.11.34.17.AM.mov

[mkhutornyi]

Cannot get account details, please try again or contact concierge@expensify.com

As the error is coming from backend, need help from internal engineer to find the exact root cause. And most likely backend bug.
🎀👀🎀

[melvin-bot]

Triggered auto assignment to @Julesssss, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[Julesssss]

Example query seems to show an invalid value of the clientUpdateID query param:

Malformed REQUEST: 'clientUpdateID' = '-1', ignoring (should match '\d{1,10}').

[Julesssss]

Front end's default value is -1, which is marked by our API input rules to be invalid. I commented on both the backend and front-end PRs to determine which is the expected behaviour.

[roryabraham]

@danieldoglas will probably know the most about this. It was originally added in the front-end with a default value of 0 in this PR.

Then it was changed to -1 in this PR.

One thing I notice is that the intention of this PR appears to have been to include clientUpdateID in write requests only (including makeRequestWithSideEffects, because that can act as a write). However, at the time that PR was added, API.read was just a wrapper around API.makeRequestWithSideEffects. So as soon as that PR was merged, clientUpdateID was being sent with every API request. In #41962 I only refactored that to make it clearer and more DRY by moving it to enhanceParameters, which runs on every request.

[iwiznia]

Oh wow... so yes, we should change the clientUpdateID waf rule to allow -1.

[iwiznia]

PR here https://github.com/Expensify/Web-Expensify/pull/42831

[iwiznia]

BTW I think it's totally fine to send clientUpdateID in all requests, even if we only need it for writes.

[Julesssss]

PR merged, thanks

[joekaufmanexpensify]

Sweet, thank you both!

[melvin-bot]

@iwiznia, @Julesssss Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[Julesssss]

Fix is on prod