ARTIFACTORY: How to resolve the 500 error for Conda-Forge Virtual Repository

ARTIFACTORY: How to resolve the 500 error for Conda-Forge Virtual Repository

AuthorFullName__c
Marwa Sharif
articleNumber
000006210
ft:sourceType
Salesforce
FirstPublishedDate
2024-10-24T18:10:30Z
lastModifiedDate
2024-10-24
VersionNumber
2
Affected Artifactory version: 7.7x.x or below

Introduction 
Customers running on Artifactory version 7.7x and lower may experience a 500 error when attempting to access the underlying virtual repository using the /api/conda/<conda-virtual-repository>/gfi/linux-64/repodata.json endpoint in a browser. This issue results in an unexpected error and prevents successful retrieval of the metadata file.
Example of a failed request:


curl <Artifactory-Url>/artifactory/api/conda/<Conda-Virtual-Repo>/linux-64/repodata.json


The request response:

{ "errors" : [ { "status" : 500, "message" : "An unexpected error has occurred, please check Artifactory logs for further details." } ] }

The Artifactory logs will display the following error:

2024-10-22T08:21:49.043Z [jfrt ] [ERROR] [85bef5bc61eb25a8] [c.e.m.GlobalExceptionMapper:52] [http-nio-8081-exec-8] - Cannot invoke "java.util.List.contains(Object)" because the return value of "org.jfrog.repomd.conda.model.RepoDataPackage.getDepends()" is null

Furthermore, the specific cause of this error is that the 'index.json' file for a package doesn't include all the keys in the metadata. When attempting to merge the metadata in the virtual repository, it may cause this issue. Thus, this issue arises when the "depends" field is missing in the index.json file of the Conda package. 

For example, this is the index.json of an issue package:

{
  "arch": "x86_64",
  "build": "rhel8_c77f2667",
  "build_number": 0,
  "constrains": [
    "fim-pkgs-staging_curl_vanilla ==7.72.0 rhel8_c77f2667"
  ],
  "name": "fim-pkgs-staging_curl_vanilla",
  "platform": "linux",
  "subdir": "linux-64",
  "timestamp": 1714685371819,
  "version": "7.72.0"
}

While other example packages look like the following:
NOTE: The difference between the 2 JSON files is that the JSON file below contains a package with dependencies and license information, plus additional metadata that indicates it's more general. 

{
  "arch": null,
  "build": "py38_0",
  "build_number": 0,
  "depends": [
    "python"
  ],
  "license": "BSD",
  "license_family": "BSD",
  "name": "0w0fyo3i9",
  "noarch": "generic",
  "platform": null,
  "subdir": "noarch",
  "timestamp": 1603887857221,
  "version": "999.0"
}


Even if there is no “depends” tag, then a package index.json file typically looks like the following with an empty “depends” tag:

{
  "arch": null,
  "build": "py38_0",
  "build_number": 0,
  "depends": [],
  "license": "BSD",
  "license_family": "BSD",
  "name": "0w0fyo3i9",
  "noarch": "generic",
  "platform": null,
  "subdir": "noarch",
  "timestamp": 1603887857221,
  "version": "999.0"
}


Resolution
To remediate the reported behavior, an upgrade of Artifactory to version 7.84.18 and above is required.

Nevertheless, if an upgrade is not feasible right away, a possible workaround is to directly point your Conda client to a remote Conda repository in Artifactory, this is since when pointing to the Virtual Conda repository Artifactory will try to merge Conda local and remote repositories which may trigger the error.