Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect interpretation of x-ratelimit-reset for Okta #76

Open
6 tasks done
morganfogg opened this issue Sep 2, 2024 · 1 comment
Open
6 tasks done

Incorrect interpretation of x-ratelimit-reset for Okta #76

morganfogg opened this issue Sep 2, 2024 · 1 comment
Labels
bug Something isn't working

Comments

@morganfogg
Copy link

morganfogg commented Sep 2, 2024

Checklist

  • I have looked into the README and have not found a suitable solution or answer.
  • I have looked into the documentation and have not found a suitable solution or answer.
  • I have searched the issues and have not found a suitable solution or answer.
  • I have upgraded to the latest version of OpenFGA and the issue still persists.
  • I have searched the Slack community and have not found a suitable solution or answer.
  • I agree to the terms within the OpenFGA Code of Conduct.

Description

Currently the rate-limit handling code interprets the contents of the x-ratelimit-reset header as a number of milliseconds from the current time to wait. (see:

However, the x-ratelimit-reset value being returned by Okta FGA is a Unix timestamp rather than an offset from the current time, meaning hitting the rate limit will theoretically cause the code to hang for ~20 days. Further down it also seems to interpret it as either a number of seconds or minutes from the current time, though this property doesn't seem to be used in the delay. An example of the headers I am receiving are:

X-Ratelimit-Limit: 30
X-Ratelimit-Remaining: 0
X-Ratelimit-Reset: 1725235793

Expectation

The SDK interprets the rate limit reset header as a Unix timestamp, or provides an option to do so.

Reproduction

  1. Perform a large number of requests against the endpoint https://api.au1.fga.dev
  2. SDK hangs indefinitely after the rate limit is hit.

OpenFGA SDK version

0.5.0

OpenFGA version

N/A

SDK Configuration

ApiUrl, StoreId, AuthorizationModelId and Credentials are provided. No other configuration.

Logs

No response

References

The header is interpreted as a number of milliseconds from the current time here:

And the delay happens here:

await Task.Delay(waitInMs);

@morganfogg morganfogg added the bug Something isn't working label Sep 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Backlog
Development

No branches or pull requests

2 participants
@morganfogg and others