Error parsing repodata.json

[willm30]

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

Hi,

Sorry in advance if this is in the wrong place.

Long story short, I'm having trouble parsing the conda-forge repodata.json, and the error message is pointing to this recipe.

Below I paste the full error message. I think the relevant section is:

(through reference chain: org.jfrog.repomd.conda.model.RepoData[\"packages.conda\"]->java.util.TreeMap[\"petsc-3.22.3-cuda11_complex_h5ce9cbd_101.conda\"]->org.jfrog.repomd.conda.model.RepoDataPackage[\"track_features\"])"

Is it possible there's a syntax error in the "track_features" field of your repodata.json?

To be honest, I'm surprised it would even be possible for one package to "break" conda-forge for others, and it's possible I'm barking up the wrong tree. But I'd be extremely grateful if you'd humour me for a second and just double-check that this isn't the case.

Full error message:

{
  "errors" : [ {
    "status" : 400,
    "message" : "com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot deserialize value of type `java.lang.String` from Array value (token `JsonToken.START_ARRAY`)\n at [Source: (org.artifactory.util.LazyStreamLoader); line: 1, column: 258079236] (through reference chain: org.jfrog.repomd.conda.model.RepoData[\"packages.conda\"]->java.util.TreeMap[\"petsc-3.22.3-cuda11_complex_h5ce9cbd_101.conda\"]->org.jfrog.repomd.conda.model.RepoDataPackage[\"track_features\"])"
  } ]
}

Thank you in advance.

Installed packages

not applicable

Environment info

Internally we're using artifactory to cache conda-forge.

[dalcinl]

I'm not sure we can do anything about it. We just migrated this package to the new recipe format, we do not even have an explicit track_features entry. I'm wondering whether this is bug in conda-build.

This is the contents of the generrated index.json.
AFAIT, there is no syntax errors in the track_features entry.

{
  "arch": "x86_64",
  "build": "cuda11_complex_h5ce9cbd_101",
  "build_number": 101,
  "depends": [
     ... not shown ...
  ],
  "license": "BSD-2-Clause",
  "name": "petsc",
  "platform": "linux",
  "subdir": "linux-64",
  "timestamp": 1738239738186,
  "track_features": [
    "petsc-p-0",
    "petsc-p-1"
  ],
  "version": "3.22.3"
}

[willm30]

Thanks for your response, we'll continue to debug internally.

[minrk]

Where is this error coming from? This is presumably a difference in the output of rattler-build from conda-build. It sounds like a bug in the code parsing the repodata and not the repodata itself, since the repodata looks correct (and is valid json) to me.

[dalcinl]

@minrk I think the following excerpt of an email sent to the petsc-maint mailing list may shed some light about what's going on. Of course, this regression is not something recipe maintainers are at fault. Maybe you know who/where to report this issue.

conda-forge started to return the field track_features as Array/List instead of String as before which broke the contract between conda and Artifactory.

Two days ago https://gitlab.com/petsc/petsc added a new package: petsc-3.22.3-cuda11_complex_he184e62_101.conda to conda forge with list of track_features ("track_features" : "petsc-p-0, petsc-p-1"):
https://conda.anaconda.org/conda-forge/linux-64/current_repodata.jso

We ask that you change the track_features field to String or remove this package from the Anaconda Registry.

[minrk]

Got it. A bit weird to send it to petsc-maint, but it's hard to keep track of who is responsible for what. Doubly weird that track_features, which absolutely is an array, would be stored as a space-separated string in repodata.

This is something to bring up with conda/rattler folks, since it is a difference in rattler-build/v1 output, and possibly not intentional.

@wolfv is it known/intentional/documented that track_features output from rattler-build doesn't follow the repodata schema here where it's a space-delimited string, not a list? Is this in the v1 CEP, or just a bug?

[wolfv]

We're working on fixing this in rattler-build. Wasn't intentional - sorry!

[dalcinl]

A bit weird to send it to petsc-maint,

The thing didn't end there. I was told that the PETSc Discord server was spammed all about this issue. The email I pasted originated from someone holding a "senior" position. I would have expected a bit more professionalism. That entitled person has a job because idiots like all us work for free to provide open source things.

[minrk]

linking things together:

• This is a bug in rattler's serialization when there's more than one feature, fixed in fix: track feature serialization and deserialization conda/rattler#1039 . That's why only builds with 2 features (cuda + complex) are affected, and why more recipes haven't seen this (it's fairly uncommon to have multiple levels of deprioritization).

The affected builds are marked as broken:

• Mark petsc as broken packages for linux-ppc64le and linux-aarch64 admin-requests#1364
• Mark petsc as broken packages admin-requests#1363

There is nothing for us to do on this feedstock other than make sure we don't publish a new build until there's a fresh rattler-build release with conda/rattler#1039

[dalcinl]

There is nothing for us to do on this feedstock

@minrk Instead of marking as broken, can't repodata be patched in this case?

[minrk]

can't repodata be patched in this case?

I believe it should be able to, but someone already marked it as broken. Since there is only one v1 build and they ought to be identical to the pre-v1 builds other than this serialization given timing, yanking the _1 builds shouldn't affect anyone (all envs should resolve with the _0 builds, and any explicit-build-pin envs can still get the broken packages without modification). So I don't think it's worth anyone's time to pursue this further, as everything is already fixed.