warehouse: Version of released package missing from `releases` in JSON API
Describe the bug
https://pypi.org/project/importlib-resources/ shows importlib-resources-5.9.0 as latest.
However, curl --silent --location --header 'Accept: application/json' https://pypi.org/pypi/importlib-resources/json | jq '.releases' | grep '5\.9\.0' does not find it.
This discrepancy is causing errors with package dependency upgrades when there is attempt to associate importlib-resources-5.9.0 with a particular file to download.

$ curl --silent --location --header 'Accept: application/json' https://pypi.org/pypi/importlib-resources/json | jq '.releases' | grep '5\.8\.1' || echo $?
"5.8.1": [
"filename": "importlib_resources-5.8.1-py3-none-any.whl",
"url": "https://files.pythonhosted.org/packages/be/1f/f5a73ba2612c0b9efb4babd07163feed72390c42655e2eb2399b3eb9ab89/importlib_resources-5.8.1-py3-none-any.whl",
$ curl --silent --location --header 'Accept: application/json' https://pypi.org/pypi/importlib-resources/json | jq '.releases' | grep '5\.9\.0' || echo $?
1
Expected behavior
releases list from JSON API should reflect what is considered the latest release in the Warehouse UI as long as releases is still being used at all.
To Reproduce
See description.
My Platform
Not particularly relevant, but I can see same problem with both curl and Python’s urllib.
Additional context
I understand that the releases portion of the response has been marked as deprecated in the JSON API, but my understanding is that it has not yet been obsoleted. Unsure if this is related to recent changes in the Warehouse code base or not - cursory inspection show there is some schema change related to releases but I have not dove deep enough to understand its relevance and possible effects.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 17 (9 by maintainers)
Yea no surrogate -key header in that. I suspect that package will resolve itself soon.
To be clear, what I think the order of operations here was:
Surrogate-Keyheader from the JSON api.Surrogate-Keyheader, with ETag X.ETagvalue ofX, since ETag only takes the body into account I think, (3) didn’t change the ETag, so Fastly got a “Not Modified”, and refreshed the cached object, without theSurrogate-Key.Surrogate-Key.ETaghas changed, since there’s noSurrogate-Keythe JSON API isn’t getting purged, but this time when the cached object expires, when Fastly does the Conditional GET, it will get a new value, with theSurrogate-Keyheader, fixing the problem into the future.[^1]: I think we just missed these URLs, because we hard purged everything that released, but that doesn’t fix everyone that got a broken cache through natural cache expiration.
I’ve manually purged jsonschema from the cache, it should be fixed now.
@miketheman @dstufft : Here’s one that my daily Github Actions task turned up a little while ago and which I just confirmed locally (i.e. from a different machine than the one that caught it, so possibly hitting a different cache node):
Edge node is:
* Connected to pypi.org (151.101.192.223) port 443Note that this is for
jsonschema-4.8.0which was reported broken by @dalthviz 10 hours ago.