Infinite loading spinner when switching from OldDot to NewDot

[roryabraham]

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

---

Action Performed:

1. Sign in with a new account on https://staging.expensify.com/ under a domain in the freePlan beta
2. Click on Set up my company for free.

Expected Result:

Workspace is created and you are taken to the workspace settings modal.

Actual Result:

Infinite loading spinner, and refreshing takes you to homepage. Since it's your first time logging into NewDot, you may also see the global create menu open up over the infinite loading spinner.

Workaround:

Refresh the page.

Platform:

Where is this issue occurring?

• Mobile Web

Version Number:
Reproducible in staging?:
Reproducible in production?:
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:
Issue reported by:
Slack conversation:

View all open jobs on GitHub

[roryabraham]

cc'ing @aldo-expensify following his comment:

I found a potential race condition race condition, but doesn't seem to be exactly the same that is happening in this GH issue because it ends up with an endless spinner in a white screen (not just a white screen)... but in case someone finds it interesting.

If you delay any of the two requests to get the getPolicyList or the getPolicySummaries from here enough, they will update the policies in Onyx removing the just created one from WorkspaceNew.js.

getPolicyList or the getPolicySummaries from here are sent after loading betas, so delaying betas request also causes the same effect.

[marcaaron]

If you delay any of the two requests to get the getPolicyList or the getPolicySummaries from here enough, they will update the policies in Onyx removing the just created one from WorkspaceNew.js.

I guess I can see how this might happen...

1. We create the policy
2. We call those two APIs
3. Policy is created and we set it in Onyx here
4. APIs return and we do not have the new policy in the local list so we remove it here

I think there are definitely issues with the underlying code working around Onyx limitations. But maybe as a quick fix we can defer fetching the list of policies until after the new workspace policy is created somehow?

[roryabraham]

Ok, something like this?

1. We send an API request to create the policy
2. We send API requests to fetch existing policies.
3. First API request returns and policy is added to Onyx.
4. Second API request(s) return, but at the time when the API was collecting the list of policies to send in the response, the new policy hadn't been created yet. So it's missing from this response and we remove it from Onyx.

[roryabraham]

Okay, following @aldo-expensify's steps, I'm able to pretty consistently reproduce this bug by:

1. Wrapping these lines in setTimeout(()=>{...}, 1000)
2. Following the steps on this issue (it must be a new account)

[roryabraham]

Two potential proposal to fix this:

1. Add a class field (not state variable) to NavigationRoot called route and set it here. Drill that as a prop through AppNavigator to AuthScreens
2. Move loadPoliciesBehindBeta inside the AuthScreens class.
3. Change it like so:

function loadPoliciesBehindBeta(betas) {
    if (!hasLoadedPolicies && this.props.route !== ROUTES.WORKSPACE_NEW && (Permissions.canUseFreePlan(betas) || Permissions.canUseDefaultRooms(betas))) {
        getPolicyList();
        getPolicySummaries();
        hasLoadedPolicies = true;
    }
}

OR

1. Add a function to Navigation.js called getCurrentRoute like so:

   function getCurrentRoute() {
       if (!navigationRef.isReady()) {
           console.debug('[Navigation] getCurrentRoute failed because navigation ref was not yet ready');
           return '';
       }
       
       return navigationRef.current.getCurrentRoute() || '';
   }

2. Change loadPoliciesBehindBeta like so:

function loadPoliciesBehindBeta(betas) {
    if (!hasLoadedPolicies && Navigation.getCurrentRoute() !== ROUTES.WORKSPACE_NEW && (Permissions.canUseFreePlan(betas) || Permissions.canUseDefaultRooms(betas))) {
        getPolicyList();
        getPolicySummaries();
        hasLoadedPolicies = true;
    }
}

[marcaaron]

Thanks @roryabraham sounds like the idea would be to just not load any policies at all if we are on the/workspace/new route?

Seems like that would definitely save us in the short term since we are really trying to cover the mainline case of a user without any policies landing in this flow. There's no need to get these policies in that case.

However, I think (still need to test) we'll still be on the /transition route when the authToken is set and LogInWithShortLivedTokenPage mounts for the second time. I guess we could check for both of those routes?

[aldo-expensify]

However, I think (still need to test) we'll still be on the /transition route when the authToken is set and LogInWithShortLivedTokenPage mounts for the second time. I guess we could check for both of those routes?

I did a small test printing window.location.href before this line and we are indeed in /transition

[aldo-expensify]

I haven't been able to reproduce this in staging. I think it is difficult for it to happen because the "Policy_Create" request seems to be much much slower than the request getting the policy list / summary, so it is always resolved after.

I marked in red the requests to get policy list and policy summary.

I think it still should be solved at some point, but I would think it is not of high priority.

[roryabraham]

I guess we could check for both of those routes?

Makes sense, we can do that too. The good news is that you can use setTimeout to reproduce this bug on dev a bit more consistently, as stated in this comment. So we can more easily test to see if it resolves the issue.

[roryabraham]

Okay, PR is up and ready for review.