[ddecrulle]

Why

#701 bumped commons-compress from 1.27.1 to 1.28.0. That version parses the gzip header "extra" field strictly, and rejects the non-standard one written by helm package (+aHR0cHM6Ly95b3V0dS5iZS96OVV6MWljandyTQo=Helm). Every chart archive then fails with:

java.io.IOException: Extra subfield lenght exceeds remaining bytes in extra: 21064 > 37
    at org.apache.commons.compress.compressors.gzip.ExtraField.fromBytes(ExtraField.java:154)
    at org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream.<init>(...)
    at fr.insee.onyxia.api.dao.universe.CatalogLoader.extractDataFromTgz(CatalogLoader.java:248)

CatalogLoader only logs this at INFO, so charts load without values.schema.json (config) and values.yaml (defaultValues). The web launcher then crashes in computeHelmValues on YAML.parse(undefined). This was seen on datalab after deploying main, and the deployment has been reverted.

What

• CatalogLoader.extractDataFromTgz reads the archive with java.util.zip.GZIPInputStream, which skips the extra field. commons-compress is still used for the tar part, so the dependency stays at 1.28.0.
• New CatalogLoaderTest.extractHelmPackagedChartTest: it extracts the existing test chart, which already has Helm's gzip header, and checks that both the schema and the default values are read. Before the fix it fails with the exact production exception.

Checked

• mvn verify: 72 tests pass, spotless OK.
• Not yet checked on a real deployment. After deploying, CatalogLoaderException should be gone from the startup logs, and latestPackages[*].defaultValues should be back in /catalogs.

Note for reviewers

These load failures were only logged at INFO, which is why the problem went unnoticed. Raising that log level could be a separate change.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud