Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

release: candidate cleanup fails with 404 deleting scheduling-candidate versions

Open Beginner friendly
  • Is something wrong?
#1,909 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
68/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
github-actions, python
Domain
ci-cd, release

Research direction

Start with release/scripts/cleanup-release-candidates.py (invoked from .github/workflows/release-candidate-cleanup.yml) and find where the per-version DELETE response is checked so the run aborts on the first 404. Read the issue's linked failing run to confirm which package stops the loop, then make the script record the failure and continue with remaining packages, exiting non-zero only after all are attempted. Done means one package's 404 no longer blocks deletion of later packages' expired versions, and the failure is still reported; the package-settings check in step 1 needs org admin access, so coordinate with a maintainer for that part.

Written by the indexing model from the issue text.

Description

area:release area:scheduling bug criticality:p3 triage:needs-implementation

What fails

Release candidate cleanup (.github/workflows/release-candidate-cleanup.yml) has failed every day since 2026-10-01; it was green through 2026-09-30. The step "Delete candidate versions older than eight days" (release/scripts/cleanup-release-candidates.py --apply) stops on the Scheduling candidate image:

release candidate cleanup failed: GitHub API DELETE https://api.github.com/orgs/registrystack/packages/container/scheduling-candidate/versions/1302456199 failed with 404: {"message":"Package not found." ...}

Example run: https://github.com/registrystack/registry-stack/actions/runs/37455706477

Likely cause (not yet confirmed)

The job deletes with the workflow GITHUB_TOKEN (packages: write). For an org container package, GitHub answers 404 rather than 403 when the token cannot manage it. The most likely explanation is that scheduling-candidate does not grant this repository's Actions admin access in its package settings ("Manage Actions access"), unlike the older candidate packages. A renamed or deleted package would give the same response, and so would a version listed through another endpoint. The package settings have not been checked yet.

To check and fix

  1. In the org package settings for scheduling-candidate, confirm the repository registrystack/registry-stack has the Admin role under Actions access. Compare with a candidate package whose cleanup succeeds.
  2. Re-run the workflow in apply mode and confirm it deletes expired scheduling-candidate versions.
  3. Decide whether one package's refusal should stop cleanup of all the others. Today the first failure ends the run, so expired versions of later packages are not deleted either.

Impact

Expired candidate images are not deleted. At minimum this affects scheduling-candidate, and possibly every package after it in the cleanup order.

Dominant language
Rust
Stars
2
Forks
0
Avg merge
9h 5m
Merged PRs (30d)
248

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from registrystack/registry-stack

All issues in registrystack/registry-stack

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.