[C+ Checklist Needs Completion] [$250] Distance - Transaction thread opens after saving distance edit when there is only one request

[kbecciv]

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: 1.4.59-0
Reproducible in staging?: y
Reproducible in production?: n
Issue reported by: Applause - Internal Team

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat that has no unsettled request.
3. Create a distance request.
4. Click on the request preview to go to one transaction report view.
5. Click Distance.
6. Edit the distance and save it.

Expected Result:

App will stay in one transaction report view after saving the distance edit because there is only one request.

Actual Result:

Transaction thread opens after saving distance edit when there is only one request.

Workaround:

n/a

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

Bug6435985_1712086676590.20240403_033400.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01034c7477c396612a
• Upwork Job ID: 1776364222315294720
• Last Price Increase: 2024-04-05
• Automatic offers:
• paultsimura | Reviewer | 0
• bernhardoj | Contributor | 0

[melvin-bot]

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

[github-actions]

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

[kbecciv]

We think that this bug might be related to #wave-collect - Release 1

[marcaaron]

I was not able to reproduce this, but ran into another bug:

A call to GetNewerActions hit a server error. Unsure if related. Checking logs...

{
  "code": 666,
  "jsonCode": 666,
  "type": "Expensify\\Libs\\Error\\ExpError",
  "UUID": "5757c554-3198-11ee-be56-0242ac120002",
  "message": "Missing reportActionID or reportID",
  "title": "",
  "data": [],
  "htmlMessage": "",
  "onyxData": [],
  "requestID": "86e4de6e880ebc79-HNL"
}

[marcaaron]

Ok, tried a second time and could not reproduce that error (worked OK).

Also can't reproduce the issue.

Expected: App will stay in one transaction report view after saving the distance edit because there is only one request.
Actual: Transaction thread opens after saving distance edit when there is only one request.

I'm not really sure what this is trying to communicate. What is a "transaction report" vs. a "transaction thread"?

I'm gonna remove the blocker and have this triaged as a normal bug.

[melvin-bot]

Triggered auto assignment to @greg-schroeder (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[bernhardoj]

Proposal

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

Saving the distance waypoints brings the user to the transaction thread.

What is the root cause of that problem?

This happens after the one transaction report page. In the expense report page, we show the money request view and pass transactionThreadReport as the report prop.

App/src/pages/home/report/ReportActionItem.tsx

Lines 756 to 773 in 879378f

	{transactionThreadReport && !isEmptyObject(transactionThreadReport) ? (
	<>
	{transactionCurrency !== report.currency && (
	<MoneyReportView
	report={report}
	policy={policy}
	shouldShowHorizontalRule={!shouldHideThreadDividerLine}
	/>
	)}
	<ShowContextMenuContext.Provider value={contextValue}>
	<MoneyRequestView
	report={transactionThreadReport}
	shouldShowHorizontalRule={!shouldHideThreadDividerLine}
	shouldShowAnimatedBackground={transactionCurrency === report.currency}
	/>
	</ShowContextMenuContext.Provider>
	</>
	) : (

transactionThreadReport is the transaction thread report object. When we open the distance edit page, it will use the passed report reportID and use it as the param.

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 354 to 356 in 879378f

	Navigation.navigate(
	ROUTES.MONEY_REQUEST_STEP_DISTANCE.getRoute(CONST.IOU.ACTION.EDIT, CONST.IOU.TYPE.REQUEST, transaction?.transactionID ?? '', report.reportID),
	)

In distance page, if we were editing, pressing save will call Navigation.dismissModal(reportID)

App/src/pages/iou/request/step/IOURequestStepDistance.js

Lines 194 to 205 in 879378f

	if (isEditing) {
	// If nothing was changed, simply go to transaction thread
	// We compare only addresses because numbers are rounded while backup
	const oldWaypoints = lodashGet(transactionBackup, 'comment.waypoints', {});
	const oldAddresses = _.mapObject(oldWaypoints, (waypoint) => _.pick(waypoint, 'address'));
	const addresses = _.mapObject(waypoints, (waypoint) => _.pick(waypoint, 'address'));
	if (_.isEqual(oldAddresses, addresses)) {
	Navigation.dismissModal(report.reportID);
	return;
	}
	IOU.updateMoneyRequestDistance(transaction.transactionID, report.reportID, waypoints);
	Navigation.dismissModal(report.reportID);

and because the reportID is the ID of the transaction thread report, we are navigated to the transaction thread report page.

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

This doesn't happen with other fields (amount, description, etc.) because when we save them, we just call Navigation.dismissModal without a reportID, so I suggest to do the same for distance page.

App/src/pages/iou/request/step/IOURequestStepAmount.js

Lines 157 to 170 in 879378f

	// If the value hasn't changed, don't request to save changes on the server and just close the modal
	if (newAmount === TransactionUtils.getAmount(transaction) && currency === TransactionUtils.getCurrency(transaction)) {
	Navigation.dismissModal();
	return;
	}
	if (isSplitBill) {
	IOU.setDraftSplitTransaction(transactionID, {amount: newAmount, currency});
	Navigation.goBack(backTo);
	return;
	}
	IOU.updateMoneyRequestAmountAndCurrency(transactionID, reportID, currency, newAmount);
	Navigation.dismissModal();

What alternative solutions did you explore? (Optional)

We can add a new param to the route to tell which report we want to go after dismissing the modal.

[greg-schroeder]

Awaiting proposal review

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~01034c7477c396612a

[melvin-bot]

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

[greg-schroeder]

Do you mind checking the proposal above @paultsimura? Thanks!

[paultsimura]

Do you mind checking the proposal above @paultsimura? Thanks!

Sure thing, will review it tomorrow 👍

[paultsimura]

The proposal by @bernhardoj looks good to me, thanks for pointing out the logic of the other fields.

🎀👀🎀 C+ reviewed

[melvin-bot]

📣 @paultsimura 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job

[melvin-bot]

📣 @bernhardoj 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

[bernhardoj]

PR is ready

cc: @paultsimura

[greg-schroeder]

Merged and deployed to staging. Awaiting deploy to prod

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

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

• Fix editing distance in one transaction report page navigates the user to transaction thread #39801

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

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

• @paultsimura requires payment automatic offer (Reviewer)
• @bernhardoj requires payment automatic offer (Contributor)

[melvin-bot]

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:

• [@paultsimura] The PR that introduced the bug has been identified. Link to the PR:
• [@paultsimura] 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:
• [@paultsimura] 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:
• [@paultsimura] Determine if we should create a regression test for this bug.
• [@paultsimura] 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.
• [@greg-schroeder] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[greg-schroeder]

Processing payments

[greg-schroeder]

Please complete the checklist @paultsimura and we can close this out!

[paultsimura]

My bad, I'm on it!

[paultsimura]

• The PR that introduced the bug has been identified. Link to the PR: Add One Transaction Report View #36934
• 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: N/A – It's just a missed piece of logic while implementing the breaking 1-transaction PR
• 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: N/A
• Determine if we should create a regression test for this bug: Yes
• 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.

Regression Test Proposal

1. Open a policy expense chat with no unsettled expense
2. Create a new distance request
3. Press the expense preview to open the one-transaction report page
4. Click Distance to open the edit distance page
5. Shuffle the waypoints
6. Press Save
7. Verify you are still on the one-transaction report page

Do we agree 👍 or 👎

[greg-schroeder]

Thanks! Filing