fix: extend tracking fallback to accept same-id-different-URL entries - #2134
Open
gnodet wants to merge 1 commit into
Open
fix: extend tracking fallback to accept same-id-different-URL entries#2134gnodet wants to merge 1 commit into
gnodet wants to merge 1 commit into
Conversation
The legacy tracking fallback added in apache#2133 handles entries written by older resolvers using ID-only keys (nid format). However, it does not handle the case where tracking entries ARE in nid_hurl format but the repository URL has changed — the scenario that breaks Maven ITs. When ITs run, the support artifacts are installed into the shared local repo from real Central, producing tracking entries like: artifact>central-<sha1(https://repo.maven.apache.org/maven2)>= Then each IT overrides central to file:target/null to prevent remote access. The resolver looks for: artifact>central-<sha1(file:target/null)>= The sha1 hashes differ, so the exact lookup misses, and the artifact is treated as 'present but unavailable'. Add a second fallback stage: after the legacy ID-only check, scan the tracking entries for any key matching the repo-ID prefix ('repoId-'). This accepts artifacts tracked under the same logical repository identity regardless of the URL hash suffix. The prefix uses 'repoId-' (with the dash separator) to avoid false positives with repos whose ID shares a prefix (e.g. 'central' must not match 'centralbackup-<sha1>').
gnodet
commented
Sep 8, 2026
gnodet
left a comment
gnodet
left a comment
Contributor
Author
There was a problem hiding this comment.
Solid fix. The prefix-based same-ID fallback correctly resolves the IT failure scenario (Central URL override producing mismatched SHA1 hashes in tracking entries). Well-guarded behind legacyTrackingFallback, thorough inline comments, and adequate test coverage.
This review was generated by an AI agent, Hermès on behalf of @gnodet.
Member
|
Does not this fully defies f013 fix? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
PR #2133 added a legacy tracking fallback for entries written by older resolvers using ID-only keys (
nidformat). However, it does not fix the actual Maven IT failures.The real problem (identified by @cstamas): when ITs run, support artifacts are installed from real Central, producing
nid_hurltracking entries:where
8fac3ebd...=sha1(https://repo.maven.apache.org/maven2).Then each IT overrides
centraltofile:target/nullto prevent remote access. The resolver looks for:The sha1 hashes differ → exact lookup misses → artifact treated as "present but unavailable" → tries to download from
file:target/null→ 💥. All 9 IT jobs fail (4229 failures across 507 test classes).Fix
Add a second fallback stage inside the existing
legacyTrackingFallbackguard: after the legacy ID-only check, scan tracking entries for any key matching the repo-ID prefix (repoId-). This accepts artifacts tracked under the same logical repository identity regardless of the URL hash suffix.The prefix uses
repoId-(with the dash separator from thenid_hurlformat) to avoid false positives with repos whose ID shares a prefix (e.g.centralmust not matchcentralbackup-<sha1>).Tests
testUrlQualifiedTrackingSameIdDifferentUrlAcceptedViaFallback: same-id-different-URL now accepted (was:assertFalse)testUrlQualifiedTrackingAcceptsSameIdDifferentUrlEntries: new — simulates the IT scenario (Central →file:target/null)Related