Skip to content

When rate limited Retry-After is not exposed #5405

Closed as not planned
Closed as not planned

Description

@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

Activity

  1. added
    needs-triageA ticket that needs to be triaged by a team member
    on Mar 20, 2025
  2. changed the title [-]Retry-After is not exposed[/-] [+]When rate limited `Retry-After` is not exposed[/+] on Mar 20, 2025
  3. added and removed
    needs-triageA ticket that needs to be triaged by a team member
    on Mar 21, 2025
  4. LekoArts commented on Mar 21, 2025

    @LekoArts
    Contributor

    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.

  5. safareli commented on Mar 21, 2025

    @safareli
    Author

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

  6. dstaley commented on Mar 25, 2025

    @dstaley
    Member

    @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.

  7. safareli commented on Mar 28, 2025

    @safareli
    Author

    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;
        }
      }
    }
  8. clerk-cookie commented on Apr 5, 2025

    @clerk-cookie
    Collaborator

    Hello 👋

    In an effort to keep our GitHub issues clean and focused, we close any issues that are awaiting a reproduction after 8 days on inactivity, and it has been 7 days. This issue will be closed tomorrow unless a reproduction is provided. If it takes longer than this to get a reproduction, that's ok, just drop a comment and we will remove the Stale label.

    How to create a minimal reproduction

    Thanks for being a part of the Clerk community! 🙏

  9. clerk-cookie commented on Apr 7, 2025

    @clerk-cookie
    Collaborator

    After 8 days without a reproduction being supplied, we are closing this issue. Keep in mind, I'm just a robot, so if I've closed this issue in error, please reply here and my human colleagues will reopen it. Likewise if a reproduction is prepared after it has been closed.

  10. safareli commented on Apr 7, 2025

    @safareli
    Author

    This is your product people including company i work at are paying for. the issue i described should be very clear to any maintainer of this lib and should not require any further work from me. yet this is closed with irrelevant reason.

  11. LekoArts commented on Apr 7, 2025

    @LekoArts
    Contributor

    Hey @safareli, this was added in #5480 and released in https://github.com/clerk/javascript/blob/main/packages/backend/CHANGELOG.md#1260. We didn't connect the PR with this issue, sorry for that!

  12. safareli commented on Apr 7, 2025

    @safareli
    Author

    That's great!

  13. safareli commented on Apr 14, 2025

    @safareli
    Author

    I tried the new version with fix, but I always get retryAfter: 0.
    The issue must be your server side backend code as the returned header value is always 0 (when i'm rate limited).
    This is screen shot of the new function you added and i can see that the returned header is "0":

    Image

    and here is one of such errors: trace id '9304f845adaf95a0-TBS'

    Image

  14. github-actions commented on Apr 15, 2026

    @github-actions
    Contributor

    This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

  15. locked as resolved and limited conversation to collaborators on Apr 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions