Incorrect time measurements in unpublish workflow prevents unpublishing
thomashoneyman opened this issue · 5 comments
As seen in:
purescript/registry#346 (comment)
...a package published just minutes prior cannot be unpublished because, and I quote:
Cannot unpublish web-fetch@4.0.0 because it was published 6063.176484722222 hours ago. Packages can only be unpublished for 48 hours after publication.
This error arises here:
registry-dev/app/src/App/API.purs
Lines 243 to 256 in 3166e09
But the real implementation is deeper, in the registry library itself:
registry-dev/lib/src/Operation/Validation.purs
Lines 133 to 158 in 3166e09
We're comparing the current time in the UTC time zone to the published time associated with the package, which is calculated here:
registry-dev/app/src/App/Effect/Source.purs
Lines 94 to 108 in 3166e09
The problem in this specific case:
- A commit to the repository was made in 2022
- The tag associated with that commit wasn't made until today
- We published the package, looked up the ref time, and voila: we see 2022 and assign that as the 'published time'
- Now the publish time is long in the past, and you can't unpublish.
The reason why we use the ref time as the publish time is to support the legacy importer, in which we need to associate old publish times so the registry doesn't say everything was published in August 2023. But we probably should be using the current time in the publish pipeline instead.
But we probably should be using the current time in the publish pipeline instead
I think there's value in preserving timestamps of old packages. We can take care of this issue by:
- distinguishing when something is coming from the legacy importer vs the new pipeline (in which it's fair to take the current time)
- allowing trustees to unpublish without any time limits - we'll need to enable this anyways for DMCA reasons.
Good point on the second note there, and I agree with you we ought to preserve time stamps for old packages
- distinguishing when something is coming from the legacy importer vs the new pipeline
Would this just amount to distinguishing between when this handle
is called from the LegacyImporter
module vs elsewhere? Effectively something like this diff here (15d747f) or would it be more involved than that?
I think you're right that it's basically choosing between two scenarios: one in which this is an import of a recent package initiated by a user's action, and one in which this is an automatic import of a legacy package. In fact, we already have a type for the distinction between the two:
registry-dev/app/src/App/API.purs
Lines 98 to 101 in 282a4f0
The easiest thing is probably to move this data type into Prelude.purs
and then have the fetch
function take it as an argument:
registry-dev/app/src/App/Effect/Source.purs
Lines 44 to 45 in 282a4f0
(The comment on the Source
data type isn't quite right, because with #255 we'll require all packages to compile; no exemption of "legacy" packages. But the idea is the same: in some ways we treat legacy packages differently than 'current' ones.)