RateLimitTransport incompatible with v4 api

[lijok]

v4, graphql api, uses POST for all operations, including read
RateLimitTransport sleeps for 1s between each POST/PATCH/PUT/DELETE operation
Say you have 100 repos with 3 branch protection rules each, the provider will spend 5 minutes sleeping

[ayk33]

Anything that can be done about this?

[lijok]

the provider needs to either not use v4 api, which is probably not wise long-term
or, rethink the RateLimitTransport

[majormoses]

I think its important to keep the RateLimitTransport for any v3 api interactions for larger organizations where we need to rely on this to get through plans in our largest states. In the graphql api I agree we need to think about rate limits very differently.

Here is the docs from Github: https://docs.github.com/en/graphql/overview/resource-limitations#rate-limit

What I think we want to do is create a generic rate limit transport and then let each rest and gql apis use the appropriate transport based on the calls.

[jcudit]

The latest release contains a possible fix for your use case. Can you take a look at the new write_delay_ms configuration parameter and let us know if this can be closed?

[lijok]

@jcudit thanks for that
set write_delay_ms to 200, which has on average sped up our plan times 2x

Lowering this value further yields marginal gains (100ms = ~6m30s)

However, while the PR that introduces write_delay_ms option helps this problem, I think long term it's not the correct solution for it. I think the provider should have separate transports for v4 and v3 api's, keeping the rate limit logic as is on the v3 api, but modifying the v4 api transport to only invoke this write delay on mutations, rather than queries

Any thoughts?

[shoddyguard]

I would have to agree that while #907 certainly helps (and is very much appreciated) it's not the solution.

As @lijok mentions It would be good to differentiate between the API's and have appropriate logic between them, this is only going to become more of a problem as more things move to the newer API.

[majormoses]

I think its important to keep the RateLimitTransport for any v3 api interactions for larger organizations where we need to rely on this to get through plans in our largest states. In the graphql api I agree we need to think about rate limits very differently.

Here is the docs from Github: https://docs.github.com/en/graphql/overview/resource-limitations#rate-limit

What I think we want to do is create a generic rate limit transport and then let each rest and gql apis use the appropriate transport based on the calls.

If we go this route we can start with adding a no-op rate limit transport for GQL apis and use the existing rate limiter for REST.

[github-actions]

👋 Hey Friends, this issue has been automatically marked as stale because it has no recent activity. It will be closed if no further activity occurs. Please add the Status: Pinned label if you feel that this issue needs to remain open/active. Thank you for your contributions and help in keeping things tidy!

[shoddyguard]

This definitely still needs addressing