Error Rate Limiting Imminent
Space developers,
We'd like to bring to your attention a feature coming to ESI very soon™ which may impact your application, depending on your use case.
As you all know, ESI does not have any rate limits. This is great for pulling down large quantities of data over a short period of time, and is something that we work hard to ensure we can keep in place. Generally speaking, we're keen to support all use cases for ESI, so long as they do not impact its use for anyone else or the performance of the EVE cluster.
In pursuit of this, we are soon going to add error limits. It's generally more expensive to complete a failed request than it is a successful one due to extra logging and/or exception capturing. Additionally, it's very common for us to see applications hit runaway conditions where they relentlessly retry on endpoints with queries that will never return a valid response. This needlessly consumes resources that could be put to better use with a bit of careful targetting.
What you may have noticed over the last week or so are some extra headers in your ESI responses. Notably, the X-ESI-Error-Limit-Remain header, which indicates how many errors responses will be returned to you in the current error window, and the X-ESI-Error-Limit-Reset header, which indicates the number of seconds until the end of the current error window.
For the moment, when X-ESI-Error-Limit-Remain reaches zero you will receive a warning header of X-ESI-Error-Limited. Once we enable this feature, you will instead recieve a 420 error response with a message encouraging more thoughtful use of resources. Once the error limit is breached, all of your queries will 420 error across all endpoints for the remainder of the error window, immediately and regardless of whether they would have succeeded or not.
Every response that is 4xx or 5xx level is counted against your limit. This includes timeout errors from ESI, due to EVE downtime or otherwise. At the current moment, we are targeting 100 allowed errors per 60 second windows.
Now would be an excellent time to add logging to your applications to look for the above mentioned headers, and to implement error-retry-backoffs if you haven't yet.
As always, to discuss this feature or anything else related to ESI, please join us in the #esi channel on tweetfleet slack. If you're not on tweetfleet slack yet, you can get an invite here -> https://www.fuzzwork.co.uk/tweetfleet-slack-invites/
With love,
-Team Tech Co