/universe/post_universe_ids fails on first request of maxItems, then reveals internal state/caching behaviour

[DaneelTrevize]

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.

[DaneelTrevize]

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

[a-tal]

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

[DaneelTrevize]

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.

[Aidansavage]

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