Skip to content

Distance - Distance and Rate fields become "pending" after returning from waypoint editor #60297

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

Closed
4 of 18 tasks
lanitochka17 opened this issue Apr 15, 2025 · 10 comments
Closed
4 of 18 tasks
Assignees
Labels
Engineering Reviewing Has a PR in review Weekly KSv2

Comments

@lanitochka17
Copy link

lanitochka17 commented Apr 15, 2025

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


Version Number: 9.1.28-1
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: 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): [email protected]
Issue reported by: Applause - Internal Team

Action Performed:

  1. Launch Expensify app
  2. Open FAB > Create expense > Distance
  3. Enter waypoints > Next
  4. On confirmation page, click Distance
  5. Click app back button

Expected Result:

Amount, Distance and Rate fields will retain its original value

Actual Result:

Amount field becomes blank, Distance and Rate fields turn to "pending" after returning from waypoint editor

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

  • Android: Standalone
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: Standalone
  • iOS: HybridApp
  • iOS: mWeb Safari
  • Windows: Chrome
  • MacOS: Chrome / Safari
  • MacOS: Desktop
Platforms Tested: On which of our officially supported platforms was this issue tested:
  • Android: Standalone
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: Standalone
  • iOS: HybridApp
  • iOS: mWeb Safari
  • Windows: Chrome
  • MacOS: Chrome / Safari
  • MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence
Bug6802818_1744731931682.ScreenRecording_04-15-2025_23-40-28_1.1.mp4

View all open jobs on GitHub

Issue OwnerCurrent Issue Owner: @waterim
@lanitochka17 lanitochka17 added the DeployBlockerCash This issue or pull request should block deployment label Apr 15, 2025
Copy link

melvin-bot bot commented Apr 15, 2025

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

Copy link

melvin-bot bot commented Apr 15, 2025

💬 A slack conversation has been started in #expensify-open-source

Copy link
Contributor

👋 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.

@gijoe0295

This comment has been minimized.

@gijoe0295
Copy link
Contributor

gijoe0295 commented Apr 15, 2025

🚨 Edited by proposal-police: This proposal was edited at 2025-04-15 18:07:00 UTC.

Proposal

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

Distance and Rate fields become "pending" after returning from waypoint editor

What is the root cause of that problem?

When we go back from the waypoint editor, we call openReport here. But the transaction.reportID in this case is an optimistic/fake report ID created when you use the global FAB. Then BE returns a report with notFound error.

Then the condition shouldUseTransactionReport is true because the report data for the fake report ID mentioned above was returned by the BE:

const shouldUseTransactionReport = transactionReport && !(isProcessingReport(transactionReport) && !policyReal?.harvesting?.enabled);
const report = shouldUseTransactionReport ? transactionReport : reportReal ?? reportDraft;

The report data above is then used to extract the linked policyID here but as this is a fake report, policyID is undefined.

The policy data is later used to get the rate here.

The rate is used to display calculate the merchant, distance and amount. The rate, merchant and distance are also saved to transactionDraft Onyx data.

const distanceMerchant = DistanceRequestUtils.getDistanceMerchant(hasRoute, distance, unit, rate ?? 0, currency ?? CONST.CURRENCY.USD, translate, toLocaleDigit);
setMoneyRequestMerchant(transactionID, distanceMerchant, true);

const distanceRequestAmount = DistanceRequestUtils.getDistanceRequestAmount(distance, unit ?? CONST.CUSTOM_UNITS.DISTANCE_UNIT_MILES, rate ?? 0);

const amount = distanceRequestAmount;
setMoneyRequestAmount(transactionID, amount, currency ?? '');

Because we don't have the rate, all the other fields are all Pending... as here and here.

So the root cause is that we saved the incorrect reportID for transactionDraft.

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

We should update transactionDraft.reportID to be the correct policy report ID that we're submitting to, not the fake/optimistic report ID.

const rateID = DistanceRequestUtils.getCustomUnitRateID(activePolicyExpenseChat?.reportID);
setCustomUnitRateID(transactionID, rateID);
setMoneyRequestParticipantsFromReport(transactionID, activePolicyExpenseChat).then(() => {
Navigation.navigate(
ROUTES.MONEY_REQUEST_STEP_CONFIRMATION.getRoute(
CONST.IOU.ACTION.CREATE,

function setMoneyRequestReportID(transactionID: string, reportID: string) {
    Onyx.merge(`${ONYXKEYS.COLLECTION.TRANSACTION_DRAFT}${transactionID}`, {reportID});
}
setCustomUnitRateID(transactionID, rateID);
setMoneyRequestReportID(transactionID, activePolicyExpenseChat?.reportID ?? '');
setMoneyRequestParticipantsFromReport(transactionID, activePolicyExpenseChat).then(() => {

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

None

What alternative solutions did you explore? (Optional)

  • Update shouldUseTransactionReport condition to exclude invalid reports (reports without reportID)

@srikarparsi
Copy link
Contributor

Looks like this was also caused by #58597 - @luacmartins @waterim could we add this to the list of follow ups?

@srikarparsi srikarparsi added Daily KSv2 and removed DeployBlockerCash This issue or pull request should block deployment Hourly KSv2 labels Apr 15, 2025
@srikarparsi
Copy link
Contributor

Hey @waterim, did you mean to comment on this PR? I see an email notification but don't see the comment here.

Copy link

melvin-bot bot commented Apr 21, 2025

@waterim Eep! 4 days overdue now. Issues have feelings too...

Copy link

melvin-bot bot commented Apr 23, 2025

@waterim 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

@luacmartins
Copy link
Contributor

This is fixed in staging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Engineering Reviewing Has a PR in review Weekly KSv2
Projects
None yet
Development

No branches or pull requests

5 participants