Provide metadata/changes.json endpoint to track updates

Our rare deletions are a manual process, so 📌 Handle release/project deletion Active should either be done first, or update that issue to include recording the deletion so it can show up in this API later.

We shouldn’t try to figure out when Composer metadata was updated from release update time or anything else, since that would be error-prone and there is some lag after that for metadata to be written. project_composer_write_json() should record what’s updated when, so the API implementation can pretty much just return data from that table.

We’re now tracking these updates, so the API can be available some time after 24h from now

https://packages.drupal.org/8/metadata/changes.json is now available.

naderman - review for this behaving as expected would be appreciated.

Implementation looks fine to me as far as I can tell that without knowing all the surrounding code, and API looks to work as expected. Thanks very much for the speedy implementation here as well!

Only question I have is in how far you have strong ordering guarantees there, e.g. when/how does the last updated timestamp for a package get set? If I get a response with a specific timestamp from the changes json, how likely is a change going to be written for that same or the previous second right afterwards due to either multiple machines processing this with slightly different clocks, or a process getting a timestamp at the beginning but running for a second or multiple before saving the data?

I spotted 2 issues:

• Dev metadata was not being logged.
• The timestamps in this were a time after the last-modified time which would be reported. That could leave clients thinking there was an update that was impossible to get. Now the actual file mtime is reported.

This was just deployed, so it will take 24h for the metadata to fully flush through.

This was deployed well over 24h ago, and there are no known issues. The timestamps should be reported exactly as the files’ mtime on disk and last modified HTTP header.

Automatically closed - issue fixed for 2 weeks with no activity.