This seems to be caused by the fact that the retry-after header is not listed among the safe headers in the access-control-expose-headers response header coming from Graph.

Because calling Graph from client-side apps is a CORS request, clients are only allowed to access a predefined set of safe headers, plus additional headers defined by the server as safe using the access-control-expose-headers header. Right now, retry-after is not listed among these headers, which is why the fetch API always returns its value as null.

To fix this issue, we'd need to add the retry-after header to the access-control-expose-headers header on Graph.

Quick update on this issue. We are working with the AGS team to add this header to the access-control-expose-headers. When available worldwide, we'll update this thread.

@sebastienlevert I'm not seeing this header in the response to graph API requests. I should expect to see it, right? (I assume you closing the topic means it was exposed at some point)

I do see retry-after listed in access-control-expose-headers but the header still isn't in the response, as you can see:

Some APIs might not send a "Retry-After" and the SDK will automatically backoff exponentially.

@sebastienlevert are you sure about the exponential backoff? Here's what I'm seeing:

Note the timestamps. Retries seem to be happening every few seconds without any backoff.

Based on this, it should https://github.com/microsoftgraph/msgraph-sdk-javascript/blob/dev/src/middleware/RetryHandler.ts#L136. What is the version of the SDK you are using?

I'm on @microsoft/microsoft-graph-client v3.0.7 (latest).

I realized what is going on: retryAttempts is capping out at 3 because of the default retry limit, and then the request fails. Then my code moves on to the next page and it does the same thing, with retryAttempts going from 0 - 3.

I am trying to fix this in my code by having a much higher maxRetries but I can't figure out how. Do I really have to create a middleware chain that replaces the default RetryHandler with a custom one, and then use that in Client.initWithMiddleware, or is there an easier way to control this?

FWIW I think it would make sense to have a MUCH higher default maxRetries value than 3 for 429 responses that don't include the retry-after header, as the first 3 retries are almost certainly going to also fail.

Even that doesn't work because RetryHandlerOptions forces you to use no more than 10 retries, which is only (with exponential backoff) 2^10 seconds in minutes, or ~17 minutes.

That's not a long enough wait for the OneNote API throttling which is per hour. I need to be able to specify a number of retries that will cause the graph API SDK to wait >= 1 hour.

Okay, I got it working with some crazy code:

/**
 * Create a new class that implements RetryHandlerOptions. We can't re-use
 * RetryHandlerOptions because it forces a max max number of retries of 10,
 * which (with exponential backoff) is only 17 minutes of retry delay, which is
 * potentially not enough. OneNote may require us to wait 1 hour before allowing
 * requests again.
 */
class HighMaxRetryHandlerOptions implements RetryHandlerOptions {
  /**
   * Matches RetryHandlerOptions.DEFAULT_DELAY
   */
  delay = 3;
  /**
   * Given the exponential backoff in the Microsoft Graph API, 12 retries means
   * we'll retry enough times to wait >= 1 hour before giving up. If waiting an
   * hour isn't long enough, the request is unlikely to succeed, and then giving
   * up makes sense.
   */
  maxRetries = 12;
  /**
   * One hour in seconds. The OneNote API limits are all described as
   * <something> per hour, so it doesn't make sense to wait more than an hour
   * between requests.
   */
  getMaxDelay() {
    return 3600;
  }
  shouldRetry() {
    return true;
  }
}

function getMiddlewareChain(): Middleware[] {
  const defaultMiddlewareChain = MiddlewareFactory.getDefaultMiddlewareChain(
    new MyCustomAuthenticationProvider()
  );

  // Create a middleware chain that has a non-default RetryHandler. The new
  // RetryHandler should have a much higher number of max retries.
  const middlewareChain = defaultMiddlewareChain.map((middleware) => {
    if (!(middleware instanceof RetryHandler)) {
      // Leave non-retry-related middleware alone
      return middleware;
    }

    // and replace RetryHandlers with our version
    return new RetryHandler(new HighMaxRetryHandlerOptions());
  });

  return middlewareChain;
}

// ... 

Client.initWithMiddleware({
  middleware: getMiddlewareChain()
});

Surely there's something much simpler that I'm missing, but this seems to be working for now:

Ideally, you shouldn't need to guess the retry value. That said, based on your observation @altano, @sebastienlevert I wonder if we should increase the retry number to 12 to accommodate the reset period of 1 hour for OneNote APIs.