[HOLD for payment 2025-02-04] [$250] Reports page - Draft report not showing in the draft status filter

[trjExpensify]

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?: 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: No
Email or phone of affected tester (no customers): customer
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @trjExpensify
Slack conversation (hyperlinked to channel name): #migrate

Action Performed:

This was a migrated user, so the open draft reports weren't created in NewDot

1. Create an open report in OldDot
2. Go to the Reports page in NewDot
3. Click the Drafts status filter

Expected Result:

The draft report should have appeared.

Actual Result:

The empty state page appears.

From @luacmartins: "Something weird happened, as I can see we sent OFFSET 100 so it seems like App thought the user was on the 3rd page of results for drafts, which is why it didn't return the single report that matched it"

Workaround:

Use OldDot

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

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021879246404932856846
• Upwork Job ID: 1879246404932856846
• Last Price Increase: 2025-01-14

Issue Owner

Current Issue Owner: @trjExpensify

[melvin-bot]

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

[melvin-bot]

Current assignee @trjExpensify is eligible for the Bug assigner, not assigning anyone new.

[melvin-bot]

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

[luacmartins]

From the logs, we can see that the Search API request was made with offset of 100 which is incorrect:

.... ORDER BY sortedTransactions.sortBy desc LIMIT 51 OFFSET 100

[ishakakkad]

Proposal

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

Reports page - Draft report not showing in the draft status filter

What is the root cause of that problem?

When we use pagination for any of the chat tabs, we set offset of last loaded page. But when we change the tab we are not resetting offset. And we load the data by using previous tab offset.

For ex, previously All Chat tab loaded 100 records using Search API, so our offset is set to 100. Now when we move to Draft Tab offset is still 100 and we call Search API using offset 100 so correct data is not render. This issue is exists in all the tabs.

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

To fix issue issue we need to reset the offset on tab change.

Solution 1 We can pass uniq key here. By passing uniq key we are make sure that whenever we change tab, search component will re-render.

<Search
    queryJSON={queryJSON}
    key={<SOME UNIQ KEY FOR TAB>}
/>

Solution 2 we can use useEffect here to reset the offset when status change.

 useEffect(() => {
        if (type === CONST.SEARCH.DATA_TYPES.CHAT) {
            setOffset(0);
        }
    }, [type, status]);

Here I added condition for CHAT type only, but we can applied for all kind reports.

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

UI bug so not sure if we can test it or not. If possible we can test if offset is reset to 0 when chat report tab is changed.

What alternative solutions did you explore? (Optional)

Na

[nkdengineer]

🚨 Edited by proposal-police: This proposal was edited at 2025-01-16 08:30:32 UTC.

Proposal

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

The empty state page appears.

What is the root cause of that problem?

The offset will increase if we fetch more results.

App/src/components/Search/index.tsx

Line 428 in 7b9e55e

setOffset(offset + CONST.SEARCH.RESULTS_PAGE_SIZE);

When we change from All to Draft, we only change the navigation param then the offset still is the previous offset. As a result, the draft report not showing.

App/src/components/Search/SearchStatusBar.tsx

Lines 180 to 182 in 7b9e55e

	const query = SearchQueryUtils.buildSearchQueryString({...queryJSON, status: item.status});
	Navigation.setParams({q: query});
	});

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

If we reset the offset whenever the status is changed, we still have a problem the Search API is still called two times, one time is the old offset, one time is the reset offset(0). This can cause the problem is the data can be displayed wrong if this tab isn't opened before and this tab has many results.

For example: We're in the All tab and the offset is 50. If the Draft tab can have 51 result, when we change from All to Draft tab the first Search API will be called with offset is 50 and it get the last data first then get 50 first result in the second API.

Screen.Recording.2025-01-16.at.15.28.33.mov

To resolve it, we can store the offset as an object that will store the offset of each tab.

const [offsetObj, setOffsetObj] = useState<Record<string, number>>({});
const offset = offsetObj[hash] ?? 0;

Then when we fetch more results, update the offset of this tab

setOffsetObj((prev) => {
    const newOffsetObj = {...prev};
    newOffsetObj[hash] = (newOffsetObj[hash] ?? 0) + CONST.SEARCH.RESULTS_PAGE_SIZE;
    return newOffsetObj;
});

App/src/components/Search/index.tsx

Line 428 in 5133090

setOffset(offset + CONST.SEARCH.RESULTS_PAGE_SIZE);

Here is the result with this solution, the API only called one time

Screen.Recording.2025-01-16.at.15.29.54.mov

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

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[hungvu193]

I created 2 open report on OD and there's no expense on draft of ND even when the offset of the params is 0.

Screen.Recording.2025-01-15.at.15.33.49.mov

[nkdengineer]

I created 2 open report on OD and there's no expense on draft of ND even when the offset of the params is 0.

@hungvu193 Can you see the response in the API? Maybe it's a case of a backend bug.

[hungvu193]

Yes I think this is BE bug, data is empty

[nkdengineer]

@hungvu193 You can try to reproduce by logging into an account that has many expenses (> 50) then scrolling until we fetch more result and then open the Draft tab.

Screen.Recording.2025-01-15.at.15.49.24.mov

[ishakakkad]

@hungvu193 This is UI issue, we are passing wrong offset parameter as mention by #55235 (comment), due to this response is empty.

[hungvu193]

There are 2 issues here:

• Open reports don't display on ND.
• Wrong offset while switching tabs.

I believe the first one should be fixed from BE. I'll review the second one, which both proposals mentioned about.

[hungvu193]

I agree about the offset RCA path of both proposals.

@nkdengineer What do you mean by this one? Doesn't that Search page will always rerender when switching from LHN?

We don't need to do that for type because when we change the type by clicking in LHN we will navigate to the new page and reset the offset.

[nkdengineer]

We don't need to do that for type because when we change the type by clicking in LHN we will navigate to the new page and reset the offset.

@hungvu193 When we click on LHN, we will navigate to a new page instead of changing the route params in the existing search page.

App/src/pages/Search/SearchTypeMenu.tsx

Lines 263 to 265 in 16ad2bc

	clearAllFilters();
	Navigation.navigate(item.getRoute(queryJSON.policyID));
	});

[hungvu193]

Ah ok, I got it. However, I think that's small detail that we can address during PR process.

[ishakakkad]

Here I added condition for CHAT type only, but we can applied for all kind reports.

@hungvu193 I already added @nkdengineer point in my proposal.

[hungvu193]

Let's go with @ishakakkad 's proposal. They were the first to propose the correct RCA and solution.

🎀 👀 🎀 C+ reviewed

[melvin-bot]

Current assignee @luacmartins is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new.

[nkdengineer]

If we reset the offset whenever the status is changed, we still have a problem the Search API is still called two times, one time is the old offset, one time is the reset offset(0). This can cause the problem is the data can be displayed wrong if this tab isn't opened before and this tab has many results.
For example: We're in the All tab and the offset is 50. If the Draft tab can have 51 result, when we change from All to Draft tab the first Search API will be called with offset is 50 and it get the last data first then get 50 first result in the second API.

@hungvu193 Just found a problem with the current solution. Please check my updated proposal again.

[ishakakkad]

Solution 1 We can pass uniq key here. By passing uniq key we are make sure that whenever we change tab, search component will re-render.

@nkdengineer @hungvu193 My first solution already fixed that issue and it is more robust.

[luacmartins]

I agree that @ishakakkad's proposal is the simplest. I think instead of just using status, we should compare hashes though since that means a new search was made and we need to reset the offset then.

[ishakakkad]

@luacmartins I have made changes but I am getting issue in Android configuration. Currently, I am fixing this, as soon as I fixed it I will create the PR.

[luacmartins]

Thanks! Feel free to create the PR as draft and link to this issue. It helps for others to see the progress on it.

[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.89-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Draft report not showing in the draft status filter #55544

If no regressions arise, payment will be issued on 2025-02-04. 🎊

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

• @hungvu193 requires payment through NewDot Manual Requests
• @ishakakkad requires payment (Needs manual offer from BZ)

[melvin-bot]

@hungvu193 @trjExpensify @hungvu193 The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[hungvu193]

BugZero Checklist:

• [Contributor] Classify the bug:

Bug classification

Source of bug:

• 1a. Result of the original design (eg. a case wasn't considered)
• 1b. Mistake during implementation
• 1c. Backend bug
• 1z. Other:

Where bug was reported:

• 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
• 2b. Reported on staging (eg. found during regression or PR testing)
• 2d. Reported on a PR
• 2z. Other:

Who reported the bug:

• 3a. Expensify user
• 3b. Expensify employee
• 3c. Contributor
• 3d. QA
• 3z. Other:

• [Contributor] 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: https://github.com/Expensify/App/pull/45617/files#r1938735253

• [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source 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

• [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

Regression Test Proposal

Precondition:

User should have at least 50 reports and at least 1 draft report

Test:

1. Login with an account that has more than 50 reports.
2. Go to Reports (Bottom tab), scroll down to the bottom to fetch more data.
3. Change the tab to Draft by click the Draft tab.
4. Verify that your Draft reports are loaded.

Do we agree 👍 or 👎

[luacmartins]

For the test steps, we need to make sure that there are draft reports, otherwise no draft reports will show up.

[hungvu193]

Ah cool. I updated the steps

[melvin-bot]

Payment Summary

Upwork Job

• Reviewer: @hungvu193 owed $250 via NewDot
• ROLE: @ishakakkad paid $(AMOUNT) via Upwork (LINK)

BugZero Checklist (@trjExpensify)

• I have verified the correct assignees and roles are listed above and updated the neccesary manual offers
• I have verified that there are no duplicate or incorrect contracts on Upwork for this job (https://www.upwork.com/ab/applicants/1879246404932856846/hired)
• I have paid out the Upwork contracts or cancelled the ones that are incorrect
• I have verified the payment summary above is correct

[trjExpensify]

Regression test request created. Payment summary as follows:

• $250 to @hungvu193 for the C+ review (Go ahead and request!)
• $250 to @ishakakkad for the PR (Offer sent!)

[trjExpensify]

Paid @ishakakkad, closing!

[garrettmknight]

$250 approved for @hungvu193