Prebuild and download checksums not matching

[ma4nn]

Problem

When prebuild_zipball and include_archive_checksum are enabled, the shasum stored in the Composer metadata (/p2/vendor/package.json) never matched the actual downloaded archive file. This causes Composer to fail checksum verification during composer install / composer update.

Root Cause

A version string mismatch between the prebuild and the download path when constructing archive filenames.

• Prebuild (Updater::updateArchive()) passed $data->getVersion() to DistManager::buildAndWriteArchive(). For a Composer PackageInterface, getVersion() returns the normalized version — e.g. 2.1.2.0 (four-part).
• Download (DistManager::getDist()) builds the cache key from $version->getVersion() on the Version entity. That method returns $this->version, which is the pretty version stored in the version column — e.g. 2.1.2 (three-part).

So for a tag like 2.1.2:

• Prebuild created and hashed: <basedir>/<vendor>/<package>/2.1.2.0-<ref>.zip → shasum stored in metadata.
• Download looked for: <basedir>/<vendor>/<package>/2.1.2-<ref>.zip → cache miss → rebuilt a fresh archive → different (non-deterministic) SHA1 than what the metadata said.

Both files ended up coexisting on disk with different contents, and the mismatch was guaranteed on every download. Dev branches (e.g. dev-release/2.1.2) were unaffected, because their pretty and normalized versions are identical — only tags triggered the bug.

Fix

Use the pretty version also for Updater::updateArchive(). This aligns the prebuild with DistManager and the Version entity, which already consistently use the pretty version for cache keys.

[craigfleming]

Reproduced on packeton/packeton:2.7.0. Diagnosis by @ma4nn is exactly right.

Worth flagging the impact is wider than the title suggests. With include_archive_checksum: false (default - no checksum verification needed), the same asymmetry instead triggers a slow synchronous lazy build on the first download of every new tag. Measured ~2 minutes for a 19 KB module on my deployment, even with prebuild_zipball: true.

On any deployment behind a CDN with a sub-100s edge timeout (Cloudflare's default is 100s), the downstream composer update receives HTTP 524 and hard-fails. First install of every release fails downstream until someone warms the zipball server-side.

Meanwhile, the lazy build runs synchronously in php-fpm and holds a worker for its full duration, so deployments with small fpm pools also see concurrent requests queue behind it.

The one-line fix here resolves it. Please consider merging.