206 partial content

getting this response code now when requesting commerce prices for a set of ids.

Is this a permanent change to only the endpoint response code, or has the max number of item ids in a request been lowered?

looks sorted now, last instance of the 206 response code was 20:02:28 UTC

so thanks, to whomever or whatever sorted it :)

-- bah, spoke too soon. Oddly, retrying the same request can return a 200.

I put in some logging around this as the 206 responses are still happening. I assume I'm not the only one seeing this...

When the 206 is returned, the returned item count is less than the requested ids, often just by one, sometimes by two.

The two examples I have from today are:08:32:29 UTC a request to commerce/prices with 128 ids returned a 206 and 126 prices. The missing ids were 84869, 8507519:02:31 UTC a request to commerce/prices with 136 ids returned a 206 and 137 prices. The missing id was 84969

The id list is retrieved by calling commerce/prices.That list is then batched into calls to commerce/prices?ids=

I assume this could be a function of bad luck of calling ids before the api cache updates and then for prices after the api cache updates, but I would suddenly be getting quite unlucky if that's the case. And as I mentioned previously, it's possible to repeat the same request with the same batch of ids 10 seconds after a 206 and receive a 200 back.

206 is the correct response when not all requested ids are part of the result. It has been this way for a looong time for the v2 APIs. Try just requesting the missing ids and you should get the reason (probably just {"text": "no such id"}). This can have many reasons.

I understand the purpose of the response code, aye.

However if this has always been happening when querying the Prices endpoint with Ids retrieved just prior from the Prices endpoint, I must have been very lucky for over a year then of regularly scraping Trading Post data. I haven't been receiving 206s up until 7 Nov 2017.

Replaying the request will often return the missing data, and the items this happens with seem to be low volume, so it feels as though there may be a mismatch with server side data caching on, perhaps, a single server in the load balancer.

i found the receipts https://github.com/codemasher/gw2-database/blame/ecb7fdc9d8acc8d2635704d6ee6c7ed31447bc05/classes/gw2items.class.php#L104The 206 exists since forever, at least since /v2- if you ran into it just now, you might as well revisit your code. The API returns it on any partial paged response as well as some others.

Ta for the gitblame.

Yes, it is normal for an API to return a 206 for partial data.

I don't find it normal for an API to return 206 and then 200 for the same request made in succession.

The multi_request function there looks like it's purpose is to multi-threaded requests, so most likely it's taking the list of item ids, and making one request for each.

The partial result is then most likely happening because at least one of those multiple requests is not returning or erroring out.

I'm not guessing, this behaviour is intended and confirmed.

also, lye said

but RE: 206, I originally thought it was a silly idea but it turns out to be super helpful for a lot of things so it'll have to be removed over my dead body