[$500] mWeb/Chrome - Distance-In offline, distance request details page loading infinitely.

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 1.4.31-2
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:

Issue found when executing PR #34604

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Go offline
3. Tap on Workspace chat which has distance request created
4. Tap on distance request to open distance request details page

Expected Result:

In offline, distance request details page must be displayed without loading

Actual Result:

In offline, distance request details page loading infinitely

Workaround:

Unknown

Workaround:

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

Bug6353506_1706118240428.az_recorder_20240124_214856.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01ed39265b86a00161
• Upwork Job ID: 1750223436772130816
• Last Price Increase: 2024-02-07

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[rojiphil]

Bringing the proposal from here

Proposal

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

In offline, the distance request details page must be displayed without loading

What is the root cause of that problem?

As there is a purposeful reduction in data sent from BE in OpenApp, the report actions for a displayed report in LHN need not be present.
This would bring about interesting scenarios in offline cases.

1. If the user is offline at this moment, the report screen will keep showing the loading status for the chat report. But, when online, the chat report actions would be fetched via openReport if the user clicks on the report in LHN.
2. Now, if the user goes offline after fetching the chat report, a similar loading status will be shown for the IOU report when clicked.
3. The same situation will repeat for the transaction report as well.

When offline, is showing a loading status in each of the above three cases intentional?

If not intentional, the proposal below can be considered.

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

To solve the problem, we can ensure that the displayed reports in LHN are fetched along with their linked reports up to a single level depth.

More specifically, we can leverage optionListItems here and ensure that all these reports are fetched once at app launch. Additionally, we can look for childReportID in Report Actions of these reports which is a good indicator of linked reports, and fetch them. This will solve points (2) and (3) mentioned in the root cause. For solving (1), we need to discuss how to arrive at this as BE support may be required. However, when minimalistic report action is sent on openApp, we can additionally look for linkedReportID.

We can implement a side effect here which looks something like this to solve the problem:

const fetchedReportIDsRef = useRef([]);
useEffect(() => {
    const arrayChildReportIDs = [];
    optionListItems.forEach((reportID) => {
        const reportActions = allReportActions[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`];
        const childReportIDs = _.filter(_.pluck(reportActions, 'childReportID'),(childReportID) => childReportID);
        if(childReportIDs.length > 0) {
            arrayChildReportIDs.push(childReportIDs);
        } 
    });
    const allRecentReportIDs = _.union(optionListItems, ...arrayChildReportIDs);
    if(currentReportID) {
        allRecentReportIDs.push(currentReportID);
    }

    const unfetchedReportIDs = _.difference(allRecentReportIDs, fetchedReportIDsRef.current);
    unfetchedReportIDs.forEach((reportID) => {
        if(!reportID) {
            return;
        }
        Report.reconnect(reportID);
        fetchedReportIDsRef.current.push(reportID);
    });        
}, [currentReportID, optionListItems, chatReports, betas, policies, priorityMode, allReportActions]);  

Additionally, we also need to include childReportID in reportActionsSelector here

What alternative solutions did you explore? (Optional)

[rojiphil]

As there is a purposeful reduction in data sent from BE in OpenApp, the report actions for a displayed report in LHN need not be present. This would bring about interesting scenarios in offline cases.

1. If the user is offline at this moment, the report screen will keep showing the loading status for the chat report. But, when online, the chat report actions would be fetched via openReport if the user clicks on the report in LHN.
2. Now, if the user goes offline after fetching the chat report, a similar loading status will be shown for the IOU report when clicked.
3. The same situation will repeat for the transaction report as well.

When offline, is showing a loading status in each of the above three cases intentional?

@sophiepintoraetz @parasharrajat
Can you please help clarify the above query as mentioned in my proposal?
Also, what would be the expected behaviour here?

[parasharrajat]

I will take a look. Currently away from laptop.

[sophiepintoraetz]

Still waiting on @parasharrajat