When rate limited `Retry-After` is not exposed

[safareli]

from docs:

If you receive a 429 error code, you have been rate limited. All subsequent requests to that specific endpoint will be blocked for a given amount of time.

Requests that have been rate limited will receive the Retry-After response header, which contains the number of seconds after which the block expires.

yet js api does not expose the Retry-After

[LekoArts]

Hello!

Please don't delete our issue template, we require users to follow it for a reason. Change your issue and fill it out completely and provide a minimal reproduction.

[safareli]

There is no minimal repro it's just not part of the api while doc states it is.

[dstaley]

@safareli In this case having a sample of code where you'd expect to be able to access the value from the retry-after header would be useful for us! I'm looking at adding support, and would love to make sure I'm adding it where you expect it to be able to be accessed.

[safareli]

I think as a user of the js/ts api one could have this two expectations. one could even implement both it's up to you but here are what I would have expected and tried to look for.:

try {
  // or any other api call
  await clerkClient.users.getUser(userId);
} catch (e) {

  // option A
  if (isClerkAPIResponseError(e) && e.status === 429) {
    // I think at this point when status is 429 e should have the retry after property on it
    // but it's probably more involved to type that way so maybe
    e.retryAfter;
  }
 // option A.2
  if (isClerkAPIResponseError(e) && e.retryAfter != null) {
    e.retryAfter;
  }

  // option B
  if(isClerkAPIResponseError(e)) {
    const tooManyRequestsError = e.errors.find((_e) => _e.code === "too_many_requests")
    if(tooManyRequestsError != null) {
      tooManyRequestsError.retryAfter;
    }
  }
}