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.

image

$ 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)

Most upvoted comments

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:

  1. A change we pushed inadvertently removed the Surrogate-Key header from the JSON api.
  2. Fastly cached a bunch of responses, without that Surrogate-Key header, with ETag X.
  3. We fixed (1)
  4. We purged those URLs (or alternatively, we missed some URLs) [^1]
  5. Fastly did a conditional get to the backend, using the ETag value of X, 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 the Surrogate-Key.
  6. Fastly continued to do (6) every 24h or so, continuously refreshing the cached object w/o Surrogate-Key.
  7. Project A releases, finally their ETag has changed, since there’s no Surrogate-Key the 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 the Surrogate-Key header, 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):

$ curl --head --verbose --location --header 'Accept: application/json' --header 'Fastly-Debug: 1' https://pypi.org/pypi/jsonschema/json | egrep '(surrogate|fastly-debug|pypi|etag)'
etag: "MSWJBwrgR1jE+dkxcgGFlw"
surrogate-control: max-age=86400, stale-while-revalidate=300, stale-if-error=86400
surrogate-key:
x-pypi-last-serial: 14406929
fastly-debug-path: (D cache-bfi-krnt7300063-BFI 1659063631) (F cache-bfi-krnt7300080-BFI 1658588462) (D cache-iad-kjyo7100124-IAD 1658588462) (F cache-iad-kjyo7100124-IAD 1658550841)
fastly-debug-ttl: (H cache-bfi-krnt7300063-BFI - - 424) (H cache-iad-kjyo7100124-IAD 48778.980 86400.000 37621)
fastly-debug-digest: c2b71dfdc359c26a52aa1c6f362af62292fdbc19166c67968435e503b1e77686

Edge node is: * Connected to pypi.org (151.101.192.223) port 443

Note that this is for jsonschema-4.8.0 which was reported broken by @dalthviz 10 hours ago.

$ curl --silent --location --header 'Accept: application/json' https://pypi.org/pypi/jsonschema/json | jq '.releases' | grep '4\.8\.0' || echo $?
1