You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
When rate limited Retry-After is not exposed #5405
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.
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 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.
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 callawaitclerkClient.users.getUser(userId);}catch(e){// option Aif(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 maybee.retryAfter;}// option A.2if(isClerkAPIResponseError(e)&&e.retryAfter!=null){e.retryAfter;}// option Bif(isClerkAPIResponseError(e)){consttooManyRequestsError=e.errors.find((_e)=>_e.code==="too_many_requests")if(tooManyRequestsError!=null){tooManyRequestsError.retryAfter;}}}
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.
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.
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.
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":
and here is one of such errors: trace id '9304f845adaf95a0-TBS'
Activity
[-]Retry-After is not exposed[/-][+]When rate limited `Retry-After` is not exposed[/+]LekoArts commentedon Mar 21, 2025
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 commentedon Mar 21, 2025
There is no minimal repro it's just not part of the api while doc states it is.
dstaley commentedon Mar 25, 2025
@safareli In this case having a sample of code where you'd expect to be able to access the value from the
retry-afterheader 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 commentedon Mar 28, 2025
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.:
clerk-cookie commentedon Apr 5, 2025
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! 🙏
clerk-cookie commentedon Apr 7, 2025
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.
safareli commentedon Apr 7, 2025
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.
LekoArts commentedon Apr 7, 2025
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!
safareli commentedon Apr 7, 2025
That's great!
safareli commentedon Apr 14, 2025
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":
and here is one of such errors: trace id '9304f845adaf95a0-TBS'
github-actions commentedon Apr 15, 2026
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.