[HOLD for payment 2024-10-29] [HOLD for payment 2024-10-25] [$250] The waypoint editor opens as a Not Found page

[m-natarajan]

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:
Reproducible in staging?: need reproduction
Reproducible in production?: needs reproduction
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?:
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @paultsimura
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1729104627493469

Action Performed:

1. Go to self-dm
2. Click "+" -> Track Expense (make sure the first tab that opens is the Distance request – if not, select it, close the RHP and start the Track Expense flow again)
3. Click the first waypoint

Expected Result:

the waypoint editor opens

Actual Result:

the "Not found" page opens

Workaround:

unknown

Platforms:

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

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Screen.Recording.2024-10-16.at.20.46.56.mov

Add any screenshot/video evidence

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021846693147955823744
• Upwork Job ID: 1846693147955823744
• Last Price Increase: 2024-10-16

Issue Owner

Current Issue Owner: @

Issue Owner

Current Issue Owner: @trjExpensify

[melvin-bot]

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

[MelvinBot]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[trjExpensify]

Hm, I can't really triage this if it's dev only. @paultsimura adding you as you reported it. 👍

[mkzie2]

Edited by proposal-police: This proposal was edited at 2024-10-16 23:18:43 UTC.

Proposal

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

the "Not found" page opens

What is the root cause of that problem?

Regression from #50772

Not found page in waypoint page would show if there's no waypoints from the draft transaction.

In this case when we get the correct request type:

App/src/pages/iou/request/IOURequestStartPage.tsx

Line 60 in a1d92ef

const transactionRequestType = useRef(TransactionUtils.getRequestType(transaction));

to init the draft transaction where we initialize the optimistic waypoints:

App/src/pages/iou/request/IOURequestStartPage.tsx

Line 68 in a1d92ef

IOU.initMoneyRequest(reportID, policy, isFromGlobalCreate, transactionRequestType.current);

App/src/libs/actions/IOU.ts

Lines 341 to 351 in 3a1d1a8

	// Add initial empty waypoints when starting a distance expense
	if (iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE) {
	comment.waypoints = {
	waypoint0: {keyForList: 'start_waypoint'},
	waypoint1: {keyForList: 'stop_waypoint'},
	};
	if (!isFromGlobalCreate) {
	const customUnitRateID = DistanceRequestUtils.getCustomUnitRateID(reportID);
	comment.customUnit = {customUnitRateID};
	}
	}

At this time the transactionDraft is null causing the transactionRequestType to be manual while it should be distance. This has not been correct all the time.

However, before #50772, we attached a screen listener that triggers onTabSelected right after the component mounts and then call resetIOUTypeIfChanged which eventually initialize the draft transaction with the correct request type (distance):

App/src/pages/iou/request/IOURequestStartPage.tsx

Line 85 in a1d92ef

IOU.initMoneyRequest(reportID, policy, isFromGlobalCreate, newIOUType);

So this works fine on staging and production.

But after #50772, onTabSelected is only triggered when we manually select a new tab:

App/src/libs/Navigation/OnyxTabNavigator.tsx

Lines 127 to 129 in 286212c

	if (selectedTab === newSelectedTab) {
	return;
	}

This causes a problem when we previously select a tab, then close the RHP and reopen the RHP, the selectedTab is still the previously selected tab, same for newSelectedTab, and thus onTabSelected is not triggered > resetIOUTypeIfChanged is not called > draft transaction is not init with the correct request type/tab.

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

We should not check the request type barely based on transaction. It is null almost the time since we clearMoneyRequest before starting any request:

App/src/pages/iou/request/IOURequestStartPage.tsx

Line 60 in a1d92ef

const transactionRequestType = useRef(TransactionUtils.getRequestType(transaction));

We can use selectedTab if transaction is undefined:

const transactionRequestType = useMemo(() => !isEmptyObject(transaction) ? TransactionUtils.getRequestType(transaction) : selectedTab, [transaction, selectedTab]);

App/src/pages/iou/request/IOURequestStartPage.tsx

Lines 63 to 69 in a1d92ef

	// Clear out the temporary expense if the reportID in the URL has changed from the transaction's reportID
	useEffect(() => {
	if (transaction?.reportID === reportID) {
	return;
	}
	IOU.initMoneyRequest(reportID, policy, isFromGlobalCreate, transactionRequestType.current);
	}, [transaction, policy, reportID, iouType, isFromGlobalCreate]);

useEffect(() => {
    if (transaction?.reportID === reportID || isLoadingSelectedTab) {
        return;
    }
    IOU.initMoneyRequest(reportID, policy, isFromGlobalCreate, transactionRequestType);
}, [transaction, policy, reportID, iouType, isFromGlobalCreate, isLoadingSelectedTab]);

What alternative solutions did you explore? (Optional)

Or we can enforce the onTabSelected is always triggered on the first render to make sure resetIOUTypeIfChanged is called with the correct request type:

App/src/libs/Navigation/OnyxTabNavigator.tsx

Lines 127 to 131 in 286212c

	if (selectedTab === newSelectedTab) {
	return;
	}
	Tab.setSelectedTab(id, newSelectedTab as SelectedTabRequest);
	onTabSelected(newSelectedTab as IOURequestType);

const didCallOnTabSelectedRef = useRef(true);

if (selectedTab === newSelectedTab && !didCallOnTabSelectedRef.current) {
    return;
}
didCallOnTabSelectedRef.current = false;
Tab.setSelectedTab(id, newSelectedTab as SelectedTabRequest);
onTabSelected(newSelectedTab as IOURequestType);

[mkzie2]

@trjExpensify I think this should be a deploy blocker as a regression from #50772 which will be deployed soon.

[trjExpensify]

Noted: #50772 (comment)

[melvin-bot]

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

[melvin-bot]

Current assignee @paultsimura is eligible for the External assigner, not assigning anyone new.

[paultsimura]

Thank you for the investigation @mkzie2.
@trjExpensify what is your take here? Do you think we should let the offending PR author @bernhardoj fix this?

🎀👀🎀 C+ reviewed

[melvin-bot]

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

[bernhardoj]

I left a comment here suggesting to fix this as a separate issue.

[paultsimura]

@bernhardoj, even though the root cause existed before, it only started to affect the flow after your PR. Therefore, it looks like a regression to me 🤔

[trjExpensify]

Yeah, I don't agree that it's a separate issue. That PR now causes users to hit an error page when they open the waypoints editor. We shouldn't send that to prod until it's fixed.

[trjExpensify]

@trjExpensify what is your take here? Do you think we should let the offending PR author @bernhardoj fix this?

Yes, I think it should be treated as a regression personally.

[paultsimura]

Ok then, tagging @rayane-djouah as the original C+ for clarity.

[bernhardoj]

We shouldn't send that to prod until it's fixed.

I agree that we should fix it before reaching prod, but the reason I personally don't think it counts as a regression is, that I or @rayane-djouah wouldn't expect that the money request initialization is not working correctly. It's a hidden bug and never works which is only discovered after the PR. There have been a few cases like this in the past.

In the past, I usually do the follow-up, but it doesn't count as a regression. I suggest treating it as a separate issue since @mkzie2 has already proposed a working solution. I can open the PR but I will borrow the solution above 😅.

[Nodebrute]

@trjExpensify We have another regression from the same pr #51029

[mkzie2]

The PR hit staging. This makes the Submit Scan/Distance expense flow completely malfunctioned and should be fixed with urgency. I can raise PR immediately if needed.

[bernhardoj]

Ok, looks like the init issue causes other flows (#51007 & #51029) too which isn't covered by the proposal, so I'm going to do the follow-up PR. I'll explain all the root causes in the PR here.

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

[trjExpensify]

@flodnv is already assigned here, removing Ben.

[melvin-bot]

⚠️ 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.

[marcaaron]

CP'd the fix I will ask for a re-test when it succeeds.

[kavimuru]

Bug is fixed.

Recording.2053.mp4

[melvin-bot]

⚠️ 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.

[melvin-bot]

⚠️ 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.

[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 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:

• Fix money request is initialized with the wrong information #51040

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

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

• @paultsimura requires payment (Needs manual offer from BZ)
• @paultsimura requires payment (Needs manual offer from BZ)

[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.
• [@trjExpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[melvin-bot]

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

• Fix money request is initialized with the wrong information #51040

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

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

• @paultsimura requires payment (Needs manual offer from BZ)
• @paultsimura requires payment (Needs manual offer from BZ)

[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.
• [@trjExpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon: