Publishing a new crate to JFrog Artifactory fails

[neoeinstein]

Problem

We're using JFrog Artifactory 7.55.9. The default behavior for Artifactory, when a crate doesn't exist, is to return a 400 Bad Request on attempts to pull information for that crate. Prior to Rust 1.83.0, this was fine, as the 400 would just cause the "wait for publish to become visible" to fail out early on the very first publish of a crate, though the crate is successfully published.

error: download of my/-c/my-crate failed
Caused by:
  failed to get successful HTTP response from `https://artifactory.mycompany.com/artifactory/api/cargo/cargo-local/index/my/-c/my-crate` (10.0.0.1), got 400
  body:
  {
    "errors" : [ {
      "status" : 400,
      "message" : "Bad Request"
    } ]
  }

However, with 1.83.0, presumably as a result of #14448, there's now a step that tries to verify that the crate is not already published. If the crate has been published at least once to Artifactory, this check passes. If it hasn't, then Artifactory returns a 400 Bad Request error that results in an unhandled error, preventing the publish from even being attempted.

I understand that this behavior was added intentionally, but it now results in breakage of a previously working process with a major vendor.

Steps

1. Establish a new JFrog Artifactory cargo repository
2. Attempt to publish a new crate to that repository that has not been published to that repository before
3. Receive a 400 Bad Request error.

Possible Solution(s)

Add a mechanism to allow skipping the "verify unpublished" check, or allow it to be tolerant of an error that doesn't explicitly indicate that the crate already exists.

Notes

No response

Version

CI doesn't run `cargo version --verbose`, but this is the output for `rustc`:

rustc 1.83.0 (90b35a623 2024-11-26)
binary: rustc
commit-hash: 90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf
commit-date: 2024-11-26
host: x86_64-unknown-linux-gnu
release: 1.83.0
LLVM version: 19.1.1

[neoeinstein]

I've been able to workaround this for the moment by downgrading to Rust/Cargo 1.82.0 and then doing the initial publish. Publishing new versions of this crate after doing this first downgraded publish should succeed.

[weihanglo]

Thanks for providing the detail!

Going to link to #13397 which seems pretty relevant to your proposed solution.

[epage]

It sounds like Artifactory is not following the specified sparse registry protocol.

On non-existent crates, the error is supposed to be

For crates that do not exist, the registry should respond with a 404 “Not Found”, 410 “Gone” or 451 “Unavailable For Legal Reasons” code.

I have not looked into what the behavior would be with the correct errors. The expectation would be that the "is published" check would gracefully handle a supported error code. We shouldn't need additional flags for this.

[earce-pulse]

this toolchain release also broke a lot of our repositories

[weihanglo]

this toolchain release also broke a lot of our repositories

@earce-pulse Mind sharing more details? Are you also using Artifactory?

[epage]

Also, has anyone reached out to JFrog about the their implementation of sparse registries?

[neoeinstein]

I filed a ticket through their support site just after filing this ticket. I've gotten a confirmation that they received the ticket, but no further information at this time.

[earce-pulse]

we are using kellnr, we have a list of project modules that depend on each other and we run

cargo publish --registry=OURREGISTRY --allow-dirty --no-verify

in order of package dependencies. where we had a depending on b we ran this for b first, then a, but now b runs and doesn't push to our repository and when a tries it fails because the release never occured

[epage]

@earce-pulse could you help clarify your situation.

You have a -> b

Your publish order is

1. 'b'
2. 'a'

which sounds like it is in dependency order, all good.

Why is b not publishing? Why is a still being published when its dependency isn't published? Why is a failing? Are any of the versions already published and, if so, why are you publishing them again? What is the expected outcome of that?