Packagist API timestamp inconsistencies

[gillarramendi]

Following on #1508

We have noticed inconsistencies when validating timestamps on changes.json and package json Last-Modified header

Example package: lightspeeddevelopment/lsx-health-plan~dev

• changes.json

    {
      "type": "update",
      "package": "lightspeeddevelopment/lsx-health-plan~dev",
      "time": 1741570585
    }

• Headers when getting package json:

date: Mon, 10 Mar 2025 11:48:16 GMT
content-type: application/json
vary: Accept-Encoding
server: BunnyCDN-IL1-1068
cdn-pullzone: 3363232
cdn-uid: 2efa5d34-cde8-4206-b9f5-369d84a45719
cdn-requestcountrycode: US
cache-control: public, max-age=86400
etag: "67ce41ec-125d"
last-modified: Mon, 10 Mar 2025 01:35:40 GMT
cdn-storageserver: DE-588
cdn-fileserver: 861
cdn-proxyver: 1.19
cdn-requestpullsuccess: True
cdn-requestpullcode: 200
cdn-cachedat: 03/10/2025 01:35:46
cdn-edgestorageid: 1232
cdn-status: 200
cdn-requesttime: 0
cdn-requestid: 7f4b73fa1390970296c191558ffe64c6
cdn-cache: HIT

• Summary:

changes.json -> 17415705850000 - Monday, 10 March 2025 01:36:25
Last-modified -> 17415705400000 - Monday, 10 March 2025 01:35:40

Last-modified is before changes.json timestamp, which is not expected as the API documentation

Is this the same as reported on #1508 or it is expected to have a delay between both timestamps?

[Seldaek]

I'm getting Mon, 10 Mar 2025 01:36:25 GMT now when fetching that file from EU and US.

There definitely might be a few seconds delay for cache purging to happen, so I'd say if you get a Last-Modified header older than changes.json timestamp it means the new file is not served yet, you should wait a sec and retry, but after a few retries (or if the expected timestamp is older than 60sec and file still not updated) then assume something is borked and skip that file/report it here. This should not take very long, and in your case per the Date header it looks like it did take over 10 hours, which isn't good.

[Seldaek]

I've reported this upstream again, but I do wonder just to understand better what's going on, how come you fetched the file so long after the update time? Are you not syncing very often or was it just because it took time for you to notice the issue and get the response headers?

[gillarramendi]

I've reported this upstream again, but I do wonder just to understand better what's going on, how come you fetched the file so long after the update time? Are you not syncing very often or was it just because it took time for you to notice the issue and get the response headers?

We retry to get the packages periodically so I just took the last log I see

[gillarramendi]

There definitely might be a few seconds delay for cache purging to happen

Thats not a problem and it is understandable, it is why we retry periodically

This should not take very long, and in your case per the Date header it looks like it did take over 10 hours, which isn't good.

Those cases are more problematic.
For example, a case I see today. New versions published yesterday (2025-03-10 17:29 UTC) https://packagist.org/packages/phalcon/ide-stubs#v5.9.0

But the version is not on the packages json yet (2025-03-11 10:07:58 GMT): https://repo.packagist.org/p2/phalcon/ide-stubs.json

Headers for investigation (job checked the package at 07:44:10, but I have the same result now):

date: Tue, 11 Mar 2025 07:44:10 GMT
content-type: application/json
vary: Accept-Encoding
server: BunnyCDN-IL1-894
cdn-pullzone: 3363232
cdn-uid: 2efa5d34-cde8-4206-b9f5-369d84a45719
cdn-requestcountrycode: US
cache-control: public, max-age=86400
etag: "67b878c7-5ab3"
last-modified: Fri, 21 Feb 2025 12:59:51 GMT
cdn-storageserver: DE-1020
cdn-fileserver: 861
cdn-proxyver: 1.19
cdn-requestpullsuccess: True
cdn-requestpullcode: 200
cdn-cachedat: 03/06/2025 15:27:01
cdn-edgestorageid: 1235
cdn-status: 200
cdn-requesttime: 0
cdn-requestid: eee60a60c88bc71c49f71b89a585ff28
cdn-cache: HIT

[Seldaek]

Could you perhaps log an error/warning and then retry from packagist.org instead of repo.packagist.org in case you get a failure? That should work around the issue without sending all traffic away from the repo subdomain..

From what I understand, the CDN provider is having random failures with the geo-replication of the data, and it might take a while until they figure this out, so it's probably best if you work around and I'll ping you once I hear something back from them.

[gillarramendi]

Could you perhaps log an error/warning and then retry from packagist.org instead of repo.packagist.org in case you get a failure? That should work around the issue without sending all traffic away from the repo subdomain.

Sounds good to me, we will test it and get back to you with the results.

[gillarramendi]

retrying from packagist.org worked fine, thanks

[Seldaek]

@gillarramendi you should be able to remove the workaround now and resume using repo.packagist.org fully, so I'll close this.

[gillarramendi]

perfect, thanks @Seldaek for the update 🙏