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

Add repair_packages task to associate missing MavenPackages from POMs in latest version

Open
  • Is something wrong?
#508 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
68/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
api, backend

Research direction

Start with MavenRepository.finalize_new_version and _ensure_packages in pulp_maven/app/models.py, then compare repair_metadata and repair_index_pages in pulp_maven/app/tasks/init.py. Trace the MavenRepositoryViewSet repair actions and migration 0011_backfill_mavenpackage before choosing the task flow. Done means the repair is idempotent, preserves repository availability, refreshes SNAPSHOT metadata, and has a test for stranded packages.

Written by the indexing model from the issue text.

Description

Problem

MavenPackage content units can exist in a domain but never become members of a repository version, so they are effectively invisible to the repository. This happens because the only code path that associates a MavenPackage with a repository version — MavenRepository._ensure_packages(), called from finalize_new_version() — is incremental: it only reconciles GAVs that appear in new_version.added() / new_version.removed(). It never does a full scan of the latest version.

Concretely, packages get stranded when:

  • The 0011_backfill_mavenpackage data migration created MavenPackage rows globally (its own docstring notes they are "created globally but NOT added to repository versions" and will only appear "on the next finalize_new_version call"). For a repository that has been static since the migration, no qualifying new version is ever created, so the backfilled packages are never associated.
  • Even when a new version is later created, only the GAVs that changed in that version get their packages added — pre-existing, untouched GAVs remain without a MavenPackage member.
  • The existing repair tasks do not help: both repair_metadata() and repair_index_pages() set _pull_through_ctx.active = True around their new_version() block, which causes finalize_new_version() to skip _ensure_packages() entirely.
Reproduction / evidence

On a repository whose latest version contains .pom artifacts but zero maven.package units, a remove-all + add-back cycle (which forces every GAV into added()) causes _ensure_packages to associate the previously-stranded packages. For example, a repo went from maven.package: 0 to maven.package: 1167 after this cycle — with no other content change. This confirms the packages already existed and were simply never associated. The remove-all/add-back workaround is heavy (minutes), doubles repo versions, and briefly empties the repository (content-serving outage window), so it is not a safe general fix.

Proposed solution

Add a repair task, e.g. repair_packages(repository_pk), that:

  1. Loads the repository's latest version.
  2. Scans all MavenArtifact units in that version, grouped by GAV, and finds every GAV that has a .pom file ({artifact_id}-{version}.pom).
  3. Creates a new repository version that:
    • For each GAV with a POM, get_or_creates the MavenPackage (scoped to the repo's domain) and adds it if not already a member. Populate/refresh metadata from the POM via update_from_pom() when a POM artifact is available (always refresh for -SNAPSHOT).
    • Optionally removes MavenPackage members whose GAV no longer has any artifact in the version (reconcile dead packages).
  4. Does not set _pull_through_ctx.active — i.e. it should be a full-scan variant of _ensure_packages that runs independent of the incremental added()/removed() gate. (Care needed if relying on finalize_new_version so metadata/index generation isn't unintentionally suppressed or doubled.)

This is essentially the full-repo counterpart to the existing incremental _ensure_packages, mirroring how repair_metadata/repair_index_pages provide full-repo regeneration for their content types.

Suggested surface

  • Task: pulp_maven/app/tasks/__init__.py::repair_packages(repository_pk)
  • Viewset action on MavenRepositoryViewSet (e.g. repair_packages/) that dispatches the task with the repository as an exclusive resource, returning the task href — consistent with existing repair endpoints.

Acceptance criteria

  • Running the task on a repo whose latest version has POMs but missing MavenPackage members creates a new version in which every GAV with a POM has a corresponding MavenPackage member.
  • Idempotent: running it again produces no changes (no new version, or an empty one) when nothing is missing.
  • -SNAPSHOT package metadata is refreshed from the current POM.
  • Does not empty the repository or cause a content-serving gap.
  • Unit/functional test covering the stranded-package scenario (POM present, package row exists in domain but not in the version → becomes a member after repair).

References

  • pulp_maven/app/models.py — MavenRepository.finalize_new_version, MavenRepository._ensure_packages
  • pulp_maven/app/tasks/__init__.py — repair_metadata, repair_index_pages (patterns to follow; note the _pull_through_ctx.active behavior)
  • pulp_maven/app/migrations/0011_backfill_mavenpackage.py — origin of the globally-created-but-unassociated packages
Dominant language
Python
Stars
5
Forks
26
Avg merge
20h 14m
Merged PRs (30d)
43

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 pulp/pulp_maven

All issues in pulp/pulp_maven

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.