Repository navigation
A failed publish job permanently blocks retrying the same package version #793
Description
I attempted to publish puppy-runtime@0.2.0.
The original publish failed because its location used a monorepo subdir:
- Job:
ea66babf-2a67-43c1-9810-1c7f52d95952 - Logs: https://www.purescript.org/registry-dev/#/jobs/ea66babf-2a67-43c1-9810-1c7f52d95952
- Original location:
katsujukou/puppy, subdirectorypuppy-runtime
I moved the package to a standalone repository and updated the manifest:
- New location: https://github.com/katsujukou/purescript-puppy-runtime
- Ref:
v0.2.0
The standalone repository's main branch and v0.2.0 tag both point to the corrected package.
However, retrying spago publish -p puppy-runtime returns the original failed job and prints its old logs. The corrected location is never processed.
The API appears to identify duplicate publish jobs only by package name and version, including completed failed jobs:
https://github.com/purescript/registry-dev/blob/master/app/src/App/Server/Router.purs#L82-L89
Could the failed job be removed or requeued so that puppy-runtime@0.2.0 can be published from the corrected location?
More generally, should completed failed jobs be excluded from duplicate detection, or should a changed payload be allowed to create a new job?
One additional detail: the failure message says “See issue #16”, but registry-dev issue #16 is closed and concerns a different historical topic.
Activity
thomashoneyman commentedon Oct 9, 2026
Thanks for flagging this — indeed, we should exclude completed failed jobs from duplicate detection. Going to open a PR in a moment to clear this for you.
thomashoneyman commentedon Oct 10, 2026
purescript/registry#567
thomashoneyman commentedon Oct 10, 2026
Reopening this following @f-f's review of #794: #794 (review).
The fix I put in does technically fix this issue, but would also open us to repeated publishes when they’re not meant such as in purescript/registry#535.
Also, allowing every failed job to run again also encourages changing the code behind an existing tag and resubmitting it.
f-f commentedon Oct 14, 2026
As I said in #794, I think this is a genuine issue that should be fixed and I think we'd be better off implementing a fix rather than reverting the previous patches. I am working on a patch that will obsolete #797 and #799
thomashoneyman commentedon Oct 14, 2026
OK, great. Feel free to close them!