[$500] Android - IOU – “Hmm.. it’s not here” appears when open existing scanning request.

[izarutskaya]

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.19-0
Reproducible in staging?: Y
Reproducible in production?: Y
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: Applause-Internal Team
Slack conversation: @

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Log in with any account.
3. Create a Scan Request in the 1:1 DM using a camera
4. Open IOU

Expected Result:

IOU opens

Actual Result:

“Hmm.. it’s not here” appears when open existing scanning request.

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

Bug6328193_1703835354378.Scan.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01ae77eeffa1097865
• Upwork Job ID: 1740696913839783936
• Last Price Increase: 2023-12-29

Issue Owner

Current Issue Owner: @laurenreidexpensify

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[melvin-bot]

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

[bernhardoj]

Proposal

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

Chat not found page shows when we open the ongoing scan request. This can happen on a manual request too.

What is the root cause of that problem?

When we do a new money request and then press the request preview before the money request API completes, we will optimistically create a new transaction thread.

App/src/components/ReportActionItem/MoneyRequestAction.js

Lines 106 to 116 in 939632e

	// If the childReportID is not present, we need to create a new thread
	const childReportID = lodashGet(action, 'childReportID', 0);
	if (!childReportID) {
	const thread = ReportUtils.buildTransactionThread(action, requestReportID);
	const userLogins = PersonalDetailsUtils.getLoginsByAccountIDs(thread.participantAccountIDs);
	Report.openReport(thread.reportID, userLogins, thread, action.reportActionID);
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(thread.reportID));
	return;
	}
	Report.openReport(childReportID);
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(childReportID));

So, now the API request queue looks like this:
[RequestMoney, OpenReport]

If we optimistically create a new thread, it will set childReportID optimistically, but it will set the childReportID to 0 if fails.

App/src/libs/actions/Report.ts

Lines 639 to 651 in 939632e

	// If we are creating a thread, ensure the report action has childReportID property added
	if (newReportObject.parentReportID && parentReportActionID) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${newReportObject.parentReportID}`,
	value: {[parentReportActionID]: {childReportID: reportID, childType: CONST.REPORT.TYPE.CHAT}},
	});
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${newReportObject.parentReportID}`,
	value: {[parentReportActionID]: {childReportID: '0', childType: ''}},
	});
	}

Currently, from what I see, creating an optimistic transaction thread will always fail.

From the log below, you can see that after the RequestMoney API completes, it will return a new childReportID, but different from the optimistic childReportID.

But because the optimistic thread fails, the childReportID becomes "0".

If you go back to the parent report, the OpenReport will be requested again for the parent report and it will return the correct childReportID, but if you press the request preview again before the OpenReport completes, it will open a report with a report ID of 0. That's why we see the not found page.

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

Don't reset the childReportID to "0" (and childType) when the open report fails, only for money request transaction thread case.

(I think technically we should reset childReportID to null/empty string)

What alternative solutions did you explore? (Optional)

Fix the issue on the BE why the optimistic transaction thread always fail

[shubham1206agra]

@bernhardoj Can you tell me why this problem only occurs on Android? Or is this problem occurs on other platforms?

[bernhardoj]

@shubham1206agra it occurs on all platforms. I debug it on the web.

[shubham1206agra]

Lets take this internal.

🎀👀🎀 C+ reviewed

[melvin-bot]

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

[shubham1206agra]

@AndrewGable Can you take this internal to see why all request have different childReportID than optimistic one?

[melvin-bot]

Current assignee @shubham1206agra is eligible for the Internal assigner, not assigning anyone new.

[melvin-bot]

@AndrewGable, @shubham1206agra, @laurenreidexpensify Eep! 4 days overdue now. Issues have feelings too...

[melvin-bot]

@AndrewGable, @shubham1206agra, @laurenreidexpensify 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[tgolen]

@AndrewGable with my brief local testing, I see this error in the logs:

403 Cannot create child report linked to an existing parent report action

Which is thrown from here: https://github.com/Expensify/Auth/blob/36a159afd4e319c3dc09a464089b5f973c80d878/auth/command/OpenReport.cpp#L218

The error happens because of the parentReportActionID that is sent in the request for OpenReport, but I don't really understand what the purpose of that error is. @chiragsalian you added that error in https://github.com/Expensify/Auth/pull/7834, is there any guidance or context you can give us about this error or what we should do to prevent it from happening?

Looking at server logs, this error happens BUNCHES:

[tgolen]

NM Chirag is on extended leave right now, so we gotta try to figure this out on our own.

[laurenreidexpensify]

Not overdue - changing track to see if #33114 solves this

[laurenreidexpensify]

Downgrading as #33114 is monthly

[laurenreidexpensify]

hold on #33114 which is currently on hold too 🙃

[laurenreidexpensify]

#33114 is now on prod, so let's get this retested and confirm if it it's been resolved, so we can close

[laurenreidexpensify]

Waiting for retesting, actually this can be a weekly

[shubham1206agra]

@laurenreidexpensify Can you get this retested?

[mvtglobally]

QA team is not able to confirm if this issue is still reproducible during KI retests as issue is Blocked to test by #27691.

[AndrewGable]

You can't test on a different Android device? I thought that issue was only a small amount of devices

[laurenreidexpensify]

@shubham1206agra pls confirm thank you

[shubham1206agra]

@laurenreidexpensify I am unable to repro this issue.
Asked in slack if someone can repro https://expensify.slack.com/archives/C02NK2DQWUX/p1712061207676789.

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[shubham1206agra]

@laurenreidexpensify We can close this.