Open DaneelTrevize opened 6 years ago
This endpoint is a hot mess right now. Can't work out what its problem is, other than large lists of inputs that are fewer than the maxItems: 1000
in count. Getting a lot of these responses for 200+ freshly queried IDs in 1 chunk, yet also had success with 480+ once some are primed. Some janky internal behaviour is leaking.
HTTP/1.1 100 Continue
HTTP/1.1 500 Internal Server Error
X-Esi-Ab-Test: 1
[body] => {"error": "Failed to read request body"}
Edit: and it's not 1 of the 7 endpoints currently not "green" according to /Meta/get_status
https://forums.eveonline.com/t/2018-04-26-mass-disconnect-due-to-ddos-attack/72277
you could probably phrase your feedback in a less negative manner. there's no need for your first and last sentence.
thanks for the feedback though, I honestly do appreciate it. but, you really need to consider your tone sometimes
Understood, but it's maddening that it behaves so seemly illogically, I've been trying to work out what threshold is tripping it out, but it seems it's more complex than that, possibly caching specific ID sets independantly regardless of set intersection.
I also just managed to have a cURL exec failed: 28: Connection timed out after 4000 milliseconds. URL: https://login.eveonline.com/oauth/token
, so I'm trying to work out how widespread problems are atm, & how reliable /Meta/get_status is.
I was unaware of the DDOS. RIP, and good luck.
Have you noticed whether most or all of the failing requests have the "x-esi-ab-test: 1" header, and the requests that succeed probably dont? It's happened with some other endpoints as well. See #881
Bug
Request
https://pastebin.com/raw/2bJpJN4X 1000 characters, i.e. maxItems.
Response
On first call, 400
Error: Bad Request
{ "error": "Invalid search!" }
Expected
200
A list of resolved character, alliance, corporation name+ID pairings
But on subsequent calls with shorter lists:
Request
https://pastebin.com/raw/Fzub5PzL
Response
https://pastebin.com/raw/zwUesY0H Duration: 1230 ms Then repeat with ~75% of the original list and again it succeeds, then repeat again with all but the last few
"Michka Dundu", "Mihailus Thellere", "Miia Lamia", "Mike Quaritch", "Mike Sarn", "Mikhail Vitsin", "Mil Sang Do", "Mileghere James"
omitted and it again suceeds.Then repeat with the full list and now it doesn't 400, but succeeds.
Request
https://pastebin.com/raw/2bJpJN4X
Response
https://pastebin.com/raw/KHN4AHXU
So it appears there's some sort of intermediate internal caching & timeout/request size limit, that if you trigger ESI to populate some pairs for a huge lookup, the differing extras in repeated requests don't trigger the 400 themselves, and eventually you've got ESI to cache all/enough that the full list can be queried for in 1 request.
Additional complications with reproducing this bug are that this ESI cache state is then maintained for (presumably) the access-control-max-age: 600seconds cache timer, or the endpoint description's 12hour timer.