Issue-6654 : Skip malformed PURLs instead of assigning to empty resolver

[sahibamittal]

Description

When a PURL fails to parse, skip it entirely rather than assigning it to an empty resolver. This prevents unnecessary resolution attempts and reduces log spam from recurring WARN messages on each cycle. Malformed PURLs are a data quality issue and should not be processed.

Added test verifying malformed PURLs are excluded from candidates and not reselected across workflow runs.

Addressed Issue

Closes #6654

Additional Details

Checklist

• I have read and understand the contributing guidelines
• This PR fixes a defect, and I have provided tests to verify that the fix is effective
• This PR implements an enhancement, and I have provided tests to verify that it works as intended
• This PR introduces changes to the database model, and I have updated the migration changelog accordingly
• This PR introduces new or alters existing behavior, and I have updated the documentation accordingly
• This PR is a substantial change (per the ADR criteria), and I have added an ADR under docs/adr/

[owasp-dt-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Coverage 100.00% diff coverage · +0.01% coverage variation

Metric	Results
Coverage variation	✅ +0.01% coverage variation (-1.00%)
Diff coverage	✅ 100.00% diff coverage (70.00%)

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (13d5b2d)	42825	37196	86.86%
Head commit (174ad48)	42822 (-3)	37199 (+3)	86.87% (+0.01%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#6679)	1	1	100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[nscuro]

Simply skipping these would cause them to always remain eligible for resolution because no result is persisted for them.

The previous behavior assigned the "empty" resolver, which then later trivially persists empty results:

dependency-track/apiserver/src/main/java/org/dependencytrack/pkgmetadata/ResolvePackageMetadataActivity.java

Lines 97 to 108 in 13d5b2d

	if (resolverName.isEmpty()) {
	// The resolver name is empty when no resolver exists that
	// supports the given batch of PURLs. In this case, simply
	// store empty results from preventing these PURLs to become
	// resolution candidates again in the next batch.
	final var buffer = new ResultBuffer();
	for (final String purlStr : purlStrings) {
	buffer.addEmptyResult(purlStr);
	}
	buffer.flush();
	return null;
	}

This prevents the next FetchPackageMetadataResolutionCandidatesRes iteration from discovering entries with invalid PURLs again.

By skipping this mechanism, ResolvePackageMetadataWorkflow would effectively loop forever and never terminate. It basically breaks the exit condition, i.e. this query returning no results:

dependency-track/apiserver/src/main/java/org/dependencytrack/pkgmetadata/FetchPackageMetadataResolutionCandidatesActivity.java

Lines 118 to 130 in 13d5b2d

	SELECT DISTINCT c."PURL"
	FROM "COMPONENT" c
	WHERE c."PURL" IS NOT NULL
	AND NOT EXISTS (
	SELECT 1
	FROM "PACKAGE_ARTIFACT_METADATA" pam
	JOIN "PACKAGE_METADATA" pm
	ON pm."PURL" = pam."PACKAGE_PURL"
	WHERE pam."PURL" = c."PURL"
	AND pm."RESOLVED_AT" > NOW() - INTERVAL '24 hours'
	)
	ORDER BY c."PURL"
	LIMIT :limit

[sahibamittal]

I'm seeing the same malformed PURL being logged on every resolution cycle with the current implementation. So the empty resolver path is not actually preventing it from being rediscovered. Same malformed PURL should not be processed again after the first successful workflow execution.
I'll check whether the empty result is being persisted and why FetchPackageMetadataResolutionCandidatesRes is still selecting it.

[sahibamittal]

Okay found it, I noticed that for the malformed PURL, ResultBuffer.addEmptyResult() returns immediately without persisting empty results because PurlUtil.silentPurl(purlStr) returns null:

final PackageURL purl = PurlUtil.silentPurl(purlStr);
if (purl == null) {
    return;
}

As a result, no PackageMetadata or PackageArtifactMetadata records are written, and the same component is selected again by FetchPackageMetadataResolutionCandidatesActivity on every cycle.