Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[HOLD for payment 2024-10-25] [$250] [P2P Distance] Split - Participants amount displayed 0.00 briefly on confirmation screen #47100

Closed
2 of 6 tasks
lanitochka17 opened this issue Aug 8, 2024 · 41 comments
Assignees
Labels
Awaiting Payment Auto-added when associated PR is deployed to production Bug Something is broken. Auto assigns a BugZero manager. Daily KSv2 Engineering External Added to denote the issue can be worked on by a contributor

Comments

@lanitochka17
Copy link

lanitochka17 commented Aug 8, 2024

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.18.3
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers): applausetester+0808pm@applause.expensifail.com
Issue reported by: Applause - Internal Team

Issue found when executing PR #42302

Action Performed:

  1. Open the app and log in
  2. Tap FAB > Split expense > Distance
  3. Tap + > Split expense > Distance
  4. Enter the start and finish viewpoints
  5. Select a few participants and proceed to the confirmation screen

Expected Result:

The correct participants amounts are displayed

Actual Result:

0.00 is briefly displayed instead of the correct amount

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

Add any screenshot/video evidence

Bug6565894_1723139401565.video_2024-08-08_13-48-49.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit
  • Upwork Job URL: https://www.upwork.com/jobs/~0170f1a1791408f62b
  • Upwork Job ID: 1821642103848571473
  • Last Price Increase: 2024-08-08
  • Automatic offers:
    • Krishna2323 | Contributor | 103497363
Issue OwnerCurrent Issue Owner: @garrettmknight
@lanitochka17 lanitochka17 added DeployBlockerCash This issue or pull request should block deployment DeployBlocker Indicates it should block deploying the API labels Aug 8, 2024
Copy link
Contributor

github-actions bot commented Aug 8, 2024

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

  1. Identify the pull request that introduced this issue and revert it.
  2. Find someone who can quickly fix the issue.
  3. Fix the issue yourself.

Copy link

melvin-bot bot commented Aug 8, 2024

Triggered auto assignment to @jasperhuangg (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

@lanitochka17
Copy link
Author

We think that this bug might be related to #vip-split

@neil-marcellini
Copy link
Contributor

Not a blocker, it's behind the distance split beta.

@neil-marcellini neil-marcellini added Daily KSv2 External Added to denote the issue can be worked on by a contributor and removed DeployBlockerCash This issue or pull request should block deployment DeployBlocker Indicates it should block deploying the API Hourly KSv2 labels Aug 8, 2024
@neil-marcellini neil-marcellini removed their assignment Aug 8, 2024
@melvin-bot melvin-bot bot changed the title Split distance - Participants amount displayed 0.00 briefly on confirmation screen [$250] Split distance - Participants amount displayed 0.00 briefly on confirmation screen Aug 8, 2024
Copy link

melvin-bot bot commented Aug 8, 2024

Job added to Upwork: https://www.upwork.com/jobs/~0170f1a1791408f62b

@melvin-bot melvin-bot bot added the Help Wanted Apply this label when an issue is open to proposals by contributors label Aug 8, 2024
Copy link

melvin-bot bot commented Aug 8, 2024

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

@neil-marcellini neil-marcellini added the Bug Something is broken. Auto assigns a BugZero manager. label Aug 8, 2024
Copy link

melvin-bot bot commented Aug 8, 2024

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

@Krishna2323
Copy link
Contributor

Proposal

Please re-state the problem that we are trying to solve in this issue.

Split distance - Participants amount displayed 0.00 briefly on confirmation screen

What is the root cause of that problem?

  • The amount and split amount for each user are calculated as a side effect after the component is rendered on the IOURequestStepConfirmation page. Initially, the amount is 0, which causes 0.00 to be displayed briefly. The calculation occurs on the second render due to the isFirstUpdatedDistanceAmount check.
    const isFirstUpdatedDistanceAmount = useRef(false);
    useEffect(() => {
    if (isFirstUpdatedDistanceAmount.current) {
    return;
    }
    if (!isDistanceRequest) {
    return;
    }
    const amount = DistanceRequestUtils.getDistanceRequestAmount(distance, unit ?? CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES, rate ?? 0);
    IOU.setMoneyRequestAmount(transactionID, amount, currency ?? '');
    isFirstUpdatedDistanceAmount.current = true;
    }, [distance, rate, unit, transactionID, currency, isDistanceRequest]);
    useEffect(() => {
    if (!shouldCalculateDistanceAmount) {
    return;
    }
    const amount = distanceRequestAmount;
    IOU.setMoneyRequestAmount(transactionID, amount, currency ?? '');
    // If it's a split request among individuals, set the split shares
    const participantAccountIDs: number[] = selectedParticipantsProp.map((participant) => participant.accountID ?? -1);
    if (isTypeSplit && !isPolicyExpenseChat && amount && transaction?.currency) {
    IOU.setSplitShares(transaction, amount, currency, participantAccountIDs);
    }
    }, [shouldCalculateDistanceAmount, distanceRequestAmount, transactionID, currency, isTypeSplit, isPolicyExpenseChat, selectedParticipantsProp, transaction]);

What changes do you think we should make in order to solve the problem?

  • We should update the amount and splitShare before moving to IOURequestStepConfirmation from IOURequestStepParticipants.
  • We can calculate the amount and split shares inside goToNextStep function in IOURequestStepParticipants.
        if (isDistanceRequest) {
            let reportUpdated = report;
            if (isPolicyExpenseChat && transaction?.participants?.[0]) {
                reportUpdated = ReportUtils.getReport(transaction?.participants?.[0].reportID ?? '') ?? report;
            }
            const policyID = IOU.getIOURequestPolicyID(transaction, reportUpdated);
            const policy = PolicyUtils.getPolicy(report?.policyID ?? policyID);
            const policyCurrency = policy?.outputCurrency ?? PolicyUtils.getPersonalPolicy()?.outputCurrency ?? CONST.CURRENCY.USD;
            const customUnitRateID = TransactionUtils.getRateID(transaction) ?? '-1';
            const mileageRates = DistanceRequestUtils.getMileageRates(policy);
            const defaultMileageRate = DistanceRequestUtils.getDefaultMileageRate(policy);
            const mileageRate = TransactionUtils.isCustomUnitRateIDForP2P(transaction)
                ? DistanceRequestUtils.getRateForP2P(policyCurrency)
                : mileageRates?.[customUnitRateID] ?? defaultMileageRate;
            const {unit, rate} = mileageRate ?? {};
            const distance = TransactionUtils.getDistanceInMeters(transaction, unit);
            const currency = (mileageRate as MileageRate)?.currency ?? policyCurrency;
            const amount = DistanceRequestUtils.getDistanceRequestAmount(distance, unit ?? CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES, rate ?? 0);
            IOU.setMoneyRequestAmount(transactionID, amount, currency ?? '');

            const participantsMap =
                transaction?.participants?.map((participant) => {
                    if (participant.isSender && iouType === CONST.IOU.TYPE.INVOICE) {
                        return participant;
                    }
                    return participant.accountID ? OptionsListUtils.getParticipantsOption(participant, personalDetails) : OptionsListUtils.getReportOption(participant);
                }) ?? [];
            const participantAccountIDs: number[] = participantsMap.map((participant) => participant.accountID ?? -1);
            if (isTypeSplit && !isPolicyExpenseChat && amount && transaction?.currency) {
                IOU.setSplitShares(transaction, amount, currency, participantAccountIDs);
            }
        }

Note

The code above is not perfect, it is just pseudocode and can be improved. It might also have some flaws, but these can be addressed after thorough testing.

What alternative solutions did you explore? (Optional)

@daledah
Copy link
Contributor

daledah commented Aug 9, 2024

Edited by proposal-police: This proposal was edited at 2024-08-09 01:17:59 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

  • The issue is that 0.00 is briefly displayed instead of the correct amount.

What is the root cause of that problem?

  • The participant's amount is calculated and displayed based on this logic:

    amount={transaction?.splitShares?.[participantOption.accountID ?? -1]?.amount}

    If the value transaction?.splitShares?.[participantOption.accountID ?? -1]?.amount is undefined, the default amount shown is 0.00.

  • In step 5, when the user navigates to the confirmation page for the first time, transaction?.splitShares is undefined, which results in an initial display of 0.00 for a brief moment.

  • Once the transaction?.splitShares data is fetched and updated via:

IOU.setSplitShares(transaction, amount, currency, participantAccountIDs);

the correct amount is displayed afterward.

What changes do you think we should make in order to solve the problem?

  • To address this, we can add a loading indicator to the input where the participant's amount is displayed. This will indicate that the amount is being calculated. Thus, the following code:

will be:

rightElement: transaction?.splitShares?.[participantOption.accountID ?? -1]?.amount !== undefined ? (
    <MoneyRequestAmountInput />
) : (
    <ActivityIndicator color={!true ? theme.textLight : theme.text} />
)

@garrettmknight
Copy link
Contributor

@parasharrajat can you give these proposals a look when you get a chance?

@melvin-bot melvin-bot bot added the Overdue label Aug 12, 2024
Copy link

melvin-bot bot commented Aug 12, 2024

@garrettmknight, @parasharrajat, @jasperhuangg Whoops! This issue is 2 days overdue. Let's get this updated quick!

Copy link

melvin-bot bot commented Oct 14, 2024

@garrettmknight, @parasharrajat, @jasperhuangg, @Krishna2323 12 days overdue now... This issue's end is nigh!

@parasharrajat
Copy link
Member

PR is close to merge.

@parasharrajat
Copy link
Member

I am no longer able to reproduce this issue on the App. But @Krishna2323 showed that the code still gets the proper values on the second render #47370 (comment). This is not visible on the UI. Should we pursue the solution further to get the values in the first render? @jasperhuangg

@Krishna2323
Copy link
Contributor

It's a lot clearer on Android. @Krishna2323 @parasharrajat is the fix you're working on still applicable to the behavior even if it doesn't come from Global Create?

@parasharrajat, have you tried this on a physical Android device? I don't have beta access to create P2P distance requests.

@parasharrajat
Copy link
Member

parasharrajat commented Oct 15, 2024

Ok. I didn't notice that. Looks like this is an issue on low-end devices. Let me get back on the PR review.

Copy link

melvin-bot bot commented Oct 17, 2024

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

@neil-marcellini
Copy link
Contributor

In the process of fixing that blocker the PR was reverted #47370. I asked on the blocker issue here if we can re-apply this PR because it sounds like maybe it didn't need to be reverted in the first place.

Either way we need to redo this and make sure it's not causing any bugs. @Krishna2323 when will you be able to put up another PR?

@neil-marcellini neil-marcellini removed the Reviewing Has a PR in review label Oct 18, 2024
@melvin-bot melvin-bot bot added Overdue Weekly KSv2 Awaiting Payment Auto-added when associated PR is deployed to production and removed Daily KSv2 labels Oct 18, 2024
@melvin-bot melvin-bot bot changed the title [$250] [P2P Distance] Split - Participants amount displayed 0.00 briefly on confirmation screen [HOLD for payment 2024-10-25] [$250] [P2P Distance] Split - Participants amount displayed 0.00 briefly on confirmation screen Oct 18, 2024
@melvin-bot melvin-bot bot removed the Overdue label Oct 18, 2024
Copy link

melvin-bot bot commented Oct 18, 2024

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.50-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

If no regressions arise, payment will be issued on 2024-10-25. 🎊

For reference, here are some details about the assignees on this issue:

Copy link

melvin-bot bot commented Oct 18, 2024

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

  • [@parasharrajat] The PR that introduced the bug has been identified. Link to the PR:
  • [@parasharrajat] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
  • [@parasharrajat] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
  • [@parasharrajat] Determine if we should create a regression test for this bug.
  • [@parasharrajat] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
  • [@garrettmknight] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

@Krishna2323
Copy link
Contributor

Krishna2323 commented Oct 18, 2024

I will raise the PR on Monday once we get confirmation on this.

@melvin-bot melvin-bot bot added Daily KSv2 and removed Weekly KSv2 labels Oct 25, 2024
@parasharrajat
Copy link
Member

parasharrajat commented Oct 26, 2024

is there something pending on this issue? @Krishna2323 It looks like the PR was reapplied #51156

@Krishna2323
Copy link
Contributor

@parasharrajat, there’s nothing pending here. @garrettmknight, this will be ready for payments in 2 days, as the reapplied PR was deployed to production 5 days ago :)

@parasharrajat
Copy link
Member

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

Regression Test Steps

  1. Open a group chat
  2. Tap + > Split expense > Distance
  3. Enter the start and finish viewpoints
  4. Verify correct participants amounts are displayed without any delay

Do you agree 👍 or 👎 ?

@garrettmknight
Copy link
Contributor

Payment Summary:

Copy link

melvin-bot bot commented Oct 28, 2024

@garrettmknight @jasperhuangg Be sure to fill out the Contact List!

@parasharrajat
Copy link
Member

Payment requested as per #47100 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting Payment Auto-added when associated PR is deployed to production Bug Something is broken. Auto assigns a BugZero manager. Daily KSv2 Engineering External Added to denote the issue can be worked on by a contributor
Projects
None yet
Development

No branches or pull requests

7 participants