Important note, for anyone reporting issues here please record a HAR file to allow us to share this with our CDN provider in a way that contains enough metadata.
See https://support.zendesk.com/hc/en-us/articles/4408828867098-Generating-a-HAR-file-for-troubleshooting
When accessing various package metadata (e.g. https://repo.packagist.org/p2/automattic/jetpack-autoloader.json), it sometimes shows outdated information for hours.
It seems #1606 was closed, but the issue remains. In particular, we've had it reported when people are accessing from non-US locations (e.g. Asia/Pacific). Perhaps there's a CDN propagation issue?
As noted in the other issue, adding a cache-buster param or via a proxy shows the updated metadata.
Pure speculation, but perhaps this is happening:
- The new version of the package is uploaded, and is recorded as updated as of timestamp X.
- A package version check hits some non-primary CDN instance, caching the page at timestamp Y.
- The main source propagates out to the CDNs, clearing cached pages of that package that are older than X.
Because the caching on step 2 occurred after X, it isn't auto-purged on step 3.
Important note, for anyone reporting issues here please record a HAR file to allow us to share this with our CDN provider in a way that contains enough metadata.
See https://support.zendesk.com/hc/en-us/articles/4408828867098-Generating-a-HAR-file-for-troubleshooting
When accessing various package metadata (e.g.
https://repo.packagist.org/p2/automattic/jetpack-autoloader.json), it sometimes shows outdated information for hours.It seems #1606 was closed, but the issue remains. In particular, we've had it reported when people are accessing from non-US locations (e.g. Asia/Pacific). Perhaps there's a CDN propagation issue?
As noted in the other issue, adding a cache-buster param or via a proxy shows the updated metadata.
Pure speculation, but perhaps this is happening:
Because the caching on step 2 occurred after X, it isn't auto-purged on step 3.