[not here] Expense - Not here page is displayed when opening a third expense in a report

[lanitochka17]

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.0.87-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A
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
Component: Money Requests

Action Performed:

1. Log into new dot with 2 different accounts on different tabs (User A and B)
2. As user A submit two manual expenses to user B
3. Navigate to the tab where you are logged in as user B and open the combined expense report (Keep the report open)
4. As user A submit another expense to user B
5. As user B open the third expense

Expected Result:

The expense report is opened

Actual Result:

"Hmm... it's not here" page is displayed

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

Add any screenshot/video evidence

Bug6717041_1737141103299.2025-01-17_22_02_24.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @yuwenmemon

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

[Kalydosos]

Proposal

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

Expense - Not here page is displayed when opening a third expense in a report

What is the root cause of that problem?

The pusher does not send the "childReportID" attribute when one more expense is sent from userA to userB

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

The issue requires a BE fix. The pusher should send the "childReportID" attribute in the reportAction when one more expense is sent from userA to userB. That attribute value is sent by userA requestMoney request as transactionThreadReportID

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

Given a money request action
When calling ROUTES.REPORT_WITH_ID.getRoute for the action childReportID
Then the result must not be "r/-1"

What alternative solutions did you explore? (Optional)

None

[melvin-bot]

@trjExpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[trjExpensify]

I can repro this. @mountiny @luacmartins do you know if there's a reason for this?

The issue requires a BE fix. The pusher should send the "childReportID" attribute in the reportAction when one more expense is sent from userA to userB. That attribute value is sent by userA requestMoney request as transactionThreadReportID

2025-01-22_14-01-09.mp4

[luacmartins]

@yuwenmemon any ideas if work done for https://github.com/Expensify/Expensify/issues/346748 could have caused this issue?

[trjExpensify]

Bump @yuwenmemon! :)

[yuwenmemon]

Hmmm... Certainly possible although we haven't done anything new for that recently (but I see this is also happening in production).

I'll have a look!

[trjExpensify]

Lavely, thanks Yuwen!

[melvin-bot]

@yuwenmemon @trjExpensify this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot]

@yuwenmemon, @trjExpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

@yuwenmemon, @trjExpensify Huh... This is 4 days overdue. Who can take care of this?

[yuwenmemon]

I had some External Commit: NSQS things come up - but should be able to look soon.

[melvin-bot]

@yuwenmemon, @trjExpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!