Bug in Registrator.jl: New package PR (for SimSpread.jl) contained two versions, one of which is not installable (and might not have ever been installable)

[DilumAluthge]

I believe that I've identified a bug in Registrator.jl that is now causing problems when trying to change a package URL. The purpose of opening this issue is three-fold:

1. Figure out how to help the package author in this specific situation.
2. Diagnose and fix the bug in Registrator.jl.
3. Add checks to AutoMerge to catch this kind of issue in the future.

The specific situation here concerns the SimSpread.jl package (located in the registry at S/SimSpread).

The SimSpread package was originally registered in October 2023; here is the new package PR: #94323

Look at the diff for #94323: https://github.com/JuliaRegistries/General/pull/94323/files

Specifically, look at the diff for S/SimSpread/Versions.toml file:

General/S/SimSpread/Versions.toml

Lines 1 to 5 in 7aa782c

	["1.0.2"]
	git-tree-sha1 = "28da8c8721266b5dfba926a66f609b8fb9337940"
	["1.0.3"]
	git-tree-sha1 = "9f4d8e3032e4d14e7f08ea5e18760d0b7cbcac57"

Somehow, Registrator.jl put two versions (1.0.2 and 1.0.3) into #94323. This (to me) seems like a clear bug. A single PR should only register a single version; this should hold true whether the PR is a new package PR or a new version PR.

Currently AutoMerge is not set up to detect this kind of situation; AutoMerge assumes that Registrator.jl generates PRs in certain ways, with "one version per PR" being one of those assumptions. So on #94323, I'm guessing that AutoMerge only ran its checks on 1.0.3, and AFAICT (from the AutoMerge comment) those checks passed, and the PR was AutoMerged.

Unfortunately, 1.0.2 was never checked by AutoMerge. And, per the author (see #145696 (comment)), there is no commit in the repo that corresponds to 1.0.2.

The author is now transferring the repo to an org (#145696), and the Treecheck is failing, because the "new repo" doesn't contain the tree for 1.0.2.

Some questions:

1. What do we do in the specific situation? Do we delete 1.0.2 from the registry? Historically, we never delete registered versions, except in very rare situations. However, this might be one of those very exceptional situations. It's not even clear to me if 1.0.2 has ever been installable.
2. Where is the bug in Registrator.jl, and how do we fix it?
3. What kind of checks can we add to AutoMerge to detect this kind of issue before merging?

[GunnarFarneback]

This is a wild case.

• The package servers don't have the 28da8c8721266b5dfba926a66f609b8fb9337940 tree hash.
• A clone of the repository also doesn't have that tree hash.
• Julia can nevertheless add version 1.0.2 (but not precompile it). Presumably this works because GitHub's API can find that tree hash, possibly because GitHub keeps more data than is visible in the repository.

I strongly suspect that 28da8c8721266b5dfba926a66f609b8fb9337940 did exist at some point but got lost after a force push.

It should be possible to add back the tree hash to the repository since the tree can be downloaded by Julia, but on the other hand it's of limited value since it can't be loaded anyway.

[ Info: Precompiling SimSpread [afa5cc60-bf5a-45b9-aa6c-27158a106b2a]
ERROR: LoadError: ArgumentError: Package SimSpread does not have Random in its dependencies:

It is indeed trying to do using Random despite not having Random as a dependency in Project.toml.

I think this is a case where it's warranted to remove a version from the registry. It shouldn't have been there in the first place and nobody can possibly have used it successfully.

[GunnarFarneback]

2. No idea how this happened. The only way to get two versions via RegistryTools is to run it twice on the same copy of the registry files. But Registrator creates a new branch when the version is changed. If there is a bug it must be related to how Registrator manages the registry files between invocations.
3. Check that a new package has exactly one entry in Versions.toml.

[GunnarFarneback]

3. More ambitious alternative: Let AutoMerge extract relevant metadata from the PR text, then call RegistryTools itself and see whether the changes match the PR. Main problem is that it requires some synchronization of RegistryTools updates between AutoMerge and Registrator.