CacheStampedeBlocker JSONObject exception

[valentijnscholten]

Current Behavior

Logs contain lots of errors trying to populate metadata cache:

2023-02-04 10:54:14,609 ERROR [CacheStampedeBlocker] An error occurred while populating cache repositoryMetaCache for key pkg:composer/magento/module-developer@100.4.5 : JSONObject["magento/module-developer"] not found.

Steps to Reproduce

Upload some SBOMS with magento modules/components such as magento/module-developer.
Wait for Metadata update jobs to complete
Observe log

Expected Behavior

It looks like its a common scenario to not being able to retrieve metadata for some components, so this should be handled more gracefully. Maybe lower to WARN or even INFO/DEBUG. Similar to what was done in #2134
Also currently the details of the exception are swallowed.
I haven't deduced yet the exact spot where this JSONObject not found error occurs.
There are 2 places where this log line is generated:

dependency-track/src/main/java/org/dependencytrack/util/CacheStampedeBlocker.java

Lines 193 to 200 in 836da60

	} catch (Exception e) {
	LOGGER.error("An error occurred while populating cache "+cacheName+" for key "+key+" : "+e.getMessage());
	if (cachePopulationFuture != null && !cachePopulationFuture.future.isDone()) {
	cachePopulationFuture.getFuture().completeExceptionally(e);
	cacheLoaders.remove(key);
	}
	return Optional.empty();
	} finally {

dependency-track/src/main/java/org/dependencytrack/util/CacheStampedeBlocker.java

Lines 216 to 219 in 836da60

	} catch (InterruptedException| ExecutionException e) {
	LOGGER.error("An error occurred while populating cache "+cacheName+" for key "+key+" : "+e.getMessage());
	return Optional.empty();
	}

Dependency-Track Version

4.7.1

Dependency-Track Distribution

Container Image

Database Server

PostgreSQL

Database Server Version

No response

Browser

Google Chrome

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this defect was already reported

[nscuro]

I remember we had a Slack discussion about properly handling 404s / "package not found" cases instead of letting them run into the default exception handling. We should definitely get this sorted. Thanks for reporting.

[valentijnscholten]

should maybe be en ehancement request instead of defect.

[valentijnscholten]

I think this will be resolved by #2327 which is not yet released. I was confused because A) I thought the fix was already released B) In 4.7.x the exception occurs in a different class which didn't sound familiar.

[nscuro]

#2327 only addressed Composer, not any of the other repo analyzers. So still a valid issue.

[valentijnscholten]

The reason I became aware of this is because this exception caused excessive retries to be done by the CacheStampedeBlocker saturating the worker threads for a long time.