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.