How to disable rate-limiting for all the subgraphs?

Server
,
1

We’re using the router as a standalone service and I’m a bit confused on how the rate limiting works in it, I’m trying to disable it completely because every now and then we receive a rate limiting error, even though we were not setting up any rate limiting in the router

[Error { message: "Your request has been rate limited", locations: [], path: Some(Path([])), extensions: {"apollo.private.subgraph.name": String("my-federated-service"), "code": String("REQUEST_RATE_LIMITED")} }]

So following the documentation I couldn’t find a clear instruction on how to disable the rate limiting, but I could find this configuration that I used to work around it by setting a very high number as shown below :backhand_index_pointing_down:, yet I am still receiving the same error, and the problem is it’s happening inconsistently.

traffic_shaping:
  router:
    timeout: 100s
  all:
    global_rate_limit:
      capacity: 1000000000 # Opening the limit with an arbitrarily high number
      interval: 1s
    timeout: 100s

And to give context we receive around 1-5k request per federated service per second the number varies depending on so may factors, my questions here are:

  • What are the default rate limiting values?, I couldn’t find it in the documentation.
  • And how can I completely disable the rate limiting or control it so that I avoid hitting it?

Thanks in advance for your support :folded_hands:

2

By default, Apollo Router does not impose global rate limits. The capacity and interval values are only applied if explicitly set in your Router config. Otherwise, rate limiting should not occur. In other words, if you remove the global_rate_limit section, that disables rate limiting.

When you first experienced the intermittent rate limiting errors, did you have global_rate_limit set or unset?

3

Hmm, it was unset, and btw, that is what I expected too, that when you leave it, no rate limit will be applied, but then we saw this error, And added these configs, and even then we still saw it, So I guess this is probably a bug. :confused: