Candidate uploads allows version overwrites

[edsko]

The official documentation states that if you want to upload another candidate, it must have a different version number. This assumption might be in various places of the code (for instance, it is assumed in the build client that if the docs for a package version have failed then they will forever fail). However, the site currently allows to upload another candidate with the same version number.

[gracenotes]

Which documentation? It might be in the wrong here. Candidates exist in different and slightly more volatile namespace. However, it doesn't seem like hooks exist to wipe the state you're talking about.

[edsko]

Well, the "Upload" page says "You can have multiple candidates for each package at the same time so long as they each have different versions". That may or may not imply what I said above.

Regarding hooks for wiping the state -- those hooks cannot exist, because that state (which packages did and did not fail to build) does not exist on the server, but is local state to the doc builder client.

[gracenotes]

Okay, I see. You can have multiple candidates for a particular version, but only serially, and there is only one available "latest" such candidate. The main difference between candidates and the main index, from the perspective of clients, is that immutability is just not a safe thing to assume for the former.

[edsko]

If that is in fact the intended behaviour then the build client must be modified to not store "failed" for package candidates (but that would mean they will be built over and over again) -- perhaps we should store a latest upload date or something.

[lambda-fairy]

It's probably wrong for the build client to assume a failing package will forever fail, even without version overwrites.

For example: consider package A depends on package B. Unfortunately, when the build client attempts package A, package B hasn't been uploaded yet (maybe the maintainer had forgotten). So package A is blacklisted, even though it should build successfully once B is released.

This kind of mistake is easy to avoid (upload dependencies first) but is currently near-impossible to fix when it does happen.

Another case to consider: we currently allow users to edit the Cabal metadata of existing packages. That could turn a failing version into a passing one as well.

Anyway, I second @edsko's solution: store the upload time along with the package ID. The server already returns an accurate Last-modified header so it's definitely viable.

This also gives us an easy way to force a rebuild. If we reset a package's timestamp, the build client will treat it as "modified" and attempt it again.