[$4000] Web-IOU- After requesting money badge in the DM flashes with red 0.00 badge before changing to green badge with requested amount

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Log in with any account
3. Click on Fab menu - Request Money
4. Put amount and click continue
5. Select user and click continue

Expected Result:

Green badge with the amount requested appears in the DM

Actual Result:

The badge is switching from 0 (red) to requested amount (green) for a brief moment

Workaround:

Unknown

Platform:

Where is this issue occurring?

• Web

Version Number: 1.1.67.0 Reproducible in staging?: Y Reproducible in production?: Y Email or phone of affected tester (no customers): [email protected] / Feya87Katya Logs: https://stackoverflow.com/c/expensify/questions/4856 Notes/Photos/Videos:

https://user-images.githubusercontent.com/43996225/170509499-d5a9571c-a6b2-42e0-b3f0-f6dd01b7bf94.mp4

Expensify/Expensify Issue URL: Issue reported by: Applause internal team Slack conversation:

View all open jobs on GitHub

[melvin-bot[bot]]

Triggered auto assignment to @techievivek (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[techievivek]

Though this can be worked externally I am picking for myself to get comfortable with the codebase.

[techievivek]

Will be looking at it today. Thanks

[techievivek]

I did get to bottom of this but not sure why I am not able to reproduce this on my machine. This is the part where we are calling the API to create the transaction. And this is the part where we re-fetch the total IOU amount and update the ONYX.

Re-applying the engineering label so they can confirm if it is reproducible and very much noticable.

[melvin-bot[bot]]

Triggered auto assignment to @bfitzexpensify (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

[bfitzexpensify]

I'm having trouble reproducing this too. I think I got it once, but it was only because I was looking out for it quite intently. I'm not sure this is noticeable enough to be worthwhile to fix.

[techievivek]

Closing this for now as per the above comments.

[kbecciv]

@techievivek @bfitzexpensify QA team is able to reproduce it with build 1.1.98.0

https://user-images.githubusercontent.com/93399543/189159634-6331328b-e978-4203-bca1-f74a85e113fb.mp4

https://user-images.githubusercontent.com/93399543/189159636-523ced51-5eb8-43db-bfec-4013d8689629.mp4

[techievivek]

I think this can be worked externally so passing it to contributors.

[melvin-bot[bot]]

Triggered auto assignment to @dylanexpensify (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

[dylanexpensify]

internal: https://www.upwork.com/ab/applicants/1569349523573489664/job-details external: https://www.upwork.com/jobs/~0119fed71c9d8ea05a

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

[sobitneupane]

Proposal Reason: I was able to reproduce the issue only twice. And found that the value of props.iouReport.ownerEmail is null at the beginning for some transaction resulting error={props.session.email !== props.iouReport.ownerEmail} to be true. Thus, badge remains red for some time.

So, I propose the following change: https://github.com/Expensify/App/blob/3d76850e2e17baeab5334d4e541e34931e57a62b/src/components/IOUBadge.js#L53-L65

    return (
+        props.iouReport.ownerEmail && props.session.email ? (
            <Badge
                pressable
                onPress={launchIOUDetailsModal}
                success={props.session.email === props.iouReport.ownerEmail}
                error={props.session.email !== props.iouReport.ownerEmail}
                text={props.numberFormat(
                    props.iouReport.total / 100,
                    {style: 'currency', currency: props.iouReport.currency},
                )}
            />
+        ) : <></>
    );

[melvin-bot[bot]]

@iwiznia, @parasharrajat, @dylanexpensify Huh... This is 4 days overdue. Who can take care of this?

[iwiznia]

@parasharrajat can you review the proposal?

[dylanexpensify]

Any updates @parasharrajat

[parasharrajat]

Coming to it in 2 hours.

[melvin-bot[bot]]

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

[parasharrajat]

Seems like simple race conditions issue. Data on optionRowLHN is updated before the real data arrives on IOUBadge. There should not be much delay between these two actions but it could be the cause of it? https://github.com/Expensify/App/blob/9ff60c3a220c9d05001007b2c0dfe0d954623edb/src/libs/actions/IOU.js#L56-L57.

It only happened once for me. I tested it with one account. A theory could be that.

1. User-created transaction.
2. Report data updated and hasOutstandingIOU became true.
3. Badge was shown to the user.
4. But the real data was not present for some reason.
5. Default props got picked on IOUBadge which resulted in 0 and red color on the badge.
6. Then real values got pushed via props and all good.

One strange thing I noticed is that once a badge becomes visible, props are first undefined.

@sobitneupane's proposal can be a solution but I don't think it is fixing the real race conditions and adding a workaround.

IMO, this is a low-priority issue but looks bad from UX perspective. `

[dylanexpensify]

coming back from OOO - reviewing today

[melvin-bot[bot]]

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

[parasharrajat]

Waiting for proposals.

[dylanexpensify]

Waiting for proposals

[dylanexpensify]

Doubling

[sobitneupane]

https://github.com/Expensify/App/blob/9ff60c3a220c9d05001007b2c0dfe0d954623edb/src/libs/actions/IOU.js#L56-L57

@parasharrajat Are these merge calls synchronous or asynchronous?

[parasharrajat]

Async.

[tsa321]

Proposal

The problem is because onyx Report and Report_IOUS are updated asynchronously when creating iou.

https://github.com/Expensify/App/blob/adc3ecea49cff208e0003e1a2b37b38ba5be8474/src/pages/home/HeaderView.js#L151-L153

hasOutstandingIOU check is depent on onyx Report, but: iouBadge component logic is based on onyx Report_Iou. Because the two collection is updated asynchronously we don't know which one is completed first, so I think we must depent our logic only on onyx Report_iou and not with onyx report.

https://github.com/Expensify/App/blob/adc3ecea49cff208e0003e1a2b37b38ba5be8474/src/components/IOUBadge.js#L39-L50

My solution is to check whether we should display IOUBadge by comparing the iourepport total with it's default props (0):

return
 ( props.iouReport.total !== defaultProps.iouReport.total && (
        <Badge
            pressable
            onPress={launchIOUDetailsModal}
            success={props.session.email === props.iouReport.ownerEmail}
            error={props.session.email !== props.iouReport.ownerEmail}
            text={props.numberFormat(
                props.iouReport.total / 100,
                {style: 'currency', currency: props.iouReport.currency},
            )}
        />)
)

Another solution is to check IOU report total and compare it with it's default value in HeaderView instead of checking hasOutstandingIOU property of the report:

https://github.com/Expensify/App/blob/adc3ecea49cff208e0003e1a2b37b38ba5be8474/src/pages/home/HeaderView.js#L151-L153

This will require withOnyx on iouReport present in HeaderView

[parasharrajat]

Thanks, @tsa321. It is kind of similar to @sobitneupane's proposal above.

I don't think it is fixing the real race conditions and adding a workaround.

My original comment remains the same. I would like to see some analysis before jumping on workarounds.

[dylanexpensify]

No updates - waiting for more proposals. @parasharrajat should we double?