[$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 [email protected] 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

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[parasharrajat]

I will checking this today,

[melvin-bot]

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

[melvin-bot]

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

[johncschuster]

@parasharrajat, did you get a chance to look at the above proposal?

[melvin-bot]

@johncschuster @parasharrajat this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[johncschuster]

This issue has the retest label applied. Coming from this process, it looks like Applause will re-test by Friday and comment with their results on Monday.

[johncschuster]

That said, this should have been tested this previous Friday and the results should be posted today-ish. @Expensify/applause, did this issue get retested in the last batch? If not, can you please add it? Thank you!

[mvtglobally]

@johncschuster Updating results right now. Give me a couple minutes. Working on it

[mvtglobally]

Issue is reproducible during KI retests.

[neil-marcellini]

I took a look and I was able to reproduce the bug as described by the test steps. Are we sure that it's specific to distance requests? Does it happen for manual or scan requests with the same steps?

Please assign me once it's time to review a proposal.

[melvin-bot]

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

[johncschuster]

@Expensify/applause

Are we sure that it's specific to distance requests? Does it happen for manual or scan requests with the same steps?

[melvin-bot]

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

[johncschuster]

@lanitochka17 / @Expensify/applause

Are we sure that it's specific to distance requests? Does it happen for manual or scan requests with the same steps?

Can you please confirm this?

[melvin-bot]

@mananjadhav, @johncschuster, @lanitochka17 Huh... This is 4 days overdue. Who can take care of this?

[johncschuster]

@lanitochka17 / @applausebot bump on this!

Are we sure that it's specific to distance requests? Does it happen for manual or scan requests with the same steps?

Can you please confirm?

[johncschuster]

Bumped in the QA channel

[kavimuru]

@johncschuster not able to reproduce this bug now.

six.mp4

dt.mp4

[johncschuster]

Great! In that case, I'm going to go ahead and close it. Thanks, @kavimuru!

[melvin-bot]

@johncschuster Be sure to fill out the Contact List!