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

Return Rate Limits #684

Open
justinormont opened this issue Nov 17, 2022 · 5 comments
Open

Return Rate Limits #684

justinormont opened this issue Nov 17, 2022 · 5 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@justinormont
Copy link

justinormont commented Nov 17, 2022

Would it be possible to return the rate limit headers for every API call? X-RateLimit-Limit, X-RateLimit-Remaining, & X-RateLimit-Reset.

Currently, there's no method of checking the current rate limit values until the limit is hit.

Once the limit is reached the values are returned in the error:

throw createError({
statusCode: error.status,
message: data?.error,
details: data?.errorDescription,
description: data?.details,
limit: error.headers.get('X-RateLimit-Limit'),
remaining: error.headers.get('X-RateLimit-Remaining'),
reset: error.headers.get('X-RateLimit-Reset'),
} as CreateErrorParams);

Alternatively, is there a way to get access to the HTTP response object, and get the headers directly?

@neet neet added the enhancement New feature or request label Nov 17, 2022
@neet
Copy link
Owner

neet commented Apr 28, 2024

I'm wondering how to design our API to address this issue.

Currently, all methods in Masto.js return the JSON API response as is. I don't want to change this behaviour as I believe that most users are happy with this, but if we also want to return HTTP headers, we need to make the return value in the so-called "enveloped" object.

// 🙁
const { data, rateLimit } = await masto.v1.accounts.$select("123").fetch();

If anyone has any ideas, please comment.

@neet neet added the help wanted Extra attention is needed label Apr 28, 2024
@cheeaun
Copy link

cheeaun commented Apr 28, 2024

For my use-case on Phanpy, would be useful to have a global event for exceeded rate limit. Writing code to check rate limit for every single API call is kinda… repetitive IMO.

RE: the return value, changing it would be a breaking change. Maybe introduce new methods? E.g. .fetchWithHeaders() that works the same as .fetch() but return "enveloped" object?

But looking at original post above, seems like maybe the expected code would be like this?:

try {
  const data = await masto.v1.accounts.$select("123").fetch();
  // Do something
} catch (e) {
  if (e.remaining <= 0) alert('Rate limit exceeded.');
  // Handle other errors
}

@neet
Copy link
Owner

neet commented Apr 28, 2024

Thanks for your opinion @cheeaun

would be useful to have a global event for exceeded rate limit

This could be a great solution because we don't need to add any new methods or changing the return type to an enveloped object... but in reality, rate limiting in Mastodon is not something global.

According to the docs, rate limit is computed within different layers. Generally, it is 300 calls per 5 minutes except for POST /api/v1/media DELETE /api/v1/statuses/:id``POST /api/v1/statuses/:id/unreblog POST /api/v1/accounts where they have a more strict limit.

This makes us to not able to implement rate limit to as a global event. It would be more precise and intuitive to let each method to have its own rate limit rather than something like this:

// pseudocode
const masto = createRestAPIClient(...)

masto.remainingCount
masto.resetDate
masto.addEventListener("rate_limit_exeed", (error) => ...)

fetchWithHeaders

You're correct... it is the most straightforward implementation, but honestly I don't want to add few dozens of additional methods to Masto.js only for this. Even though we now have moved to Proxy API, we still need to add type definitions for these new methods.

I think the relative costs for maintaining these new methods overweigh the advantages for developers who need rate limiting.

expected code would be like this

As @justinormont pointed out, we used to offer an error class dedicated for rate limit error. However, it wasn't that useful since it only tells you the remaining count after reaching to the limit. I remember I removed this error class at some point to reduce the bundle size.

@neet
Copy link
Owner

neet commented Apr 28, 2024

I'm thinking something like this but I'm not sure if I can actually implement it

// rate limits are saved in-memory inside the REST API client for each method
masto.v1.accounts.fetch.remaining
masto.v1.accounts.fetch.reset
masto.v1.accounts.fetch.limit

// you can still call the method
masto.v1.accounts.fetch()

@Isaw-w
Copy link

Isaw-w commented Sep 10, 2024

Any update?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants