I wonder if this should be renamed to authInProgress to improve readability. This is technically a bit inaccurate, as the "delay" at the end is not really part of auth... but in my opinion, it's more clear. Otherwise when I first see this, I'm thinking it's a permissions thing, or something to do with required data being available

When cancel is called, we currently need to wait for one of the if (cancelled) lines below before setCanPerformAuth(true) is run.

As a result, when something changes, a second auth has to wait a little before it can start.

Is there a downside to immediately starting the second auth? What would happen if we added setCanPerformAuth(true) here, removed line 162, and made line 178 conditional on cancelled being false?

Nit: is this line necessary? I think the finally block will still execute before the return, but I may be wrong

If for some reason the access token disappears from Redux (for instance, an identity session invalidation), should we also cancel a pending auth?

I'm not sure I understand the need for the prevPerformAuth ref.

What would be wrong with this code?

React.useEffect(() => {
  if (
    !usingCommServicesAccessToken ||
    isUserAuthenticated ||
    !hasAccessToken
  ) {
    return;
  }
  cancelPendingAuth.current?.();
  cancelPendingAuth.current = null;
  if (!canPerformAuth) {
    return;
  }
  const [, cancel] = performAuth();
  cancelPendingAuth.current = cancel;
}, [canPerformAuth, hasAccessToken, isUserAuthenticated, performAuth]);

Is the concern that perhaps one of the boolean deps could flip twice, resulting in a login being cancelled unnecessarily?

I wonder if we should set cancelPendingAuth.current = null here. I don't think it's very important, but seems more "correct", to avoid cancelling multiple times (which should be a no-op)