Last Friday (March 8), we deployed a change to crates.io that affects how the index is updated. Previously, we updated the index synchronously on the web server before sending a response to cargo. This is no longer the case.
When you run
cargo publish or
cargo yank, the index update is now queued to be run asynchronously, off the web server. This means that
cargo publish returning with no error does not mean the newly published version can be used from
This should not be noticeable the majority of the time. The delay is typically less than 1 second, and the longest we’ve observed is around 3 seconds. We are hoping to lower this further in the near future. Typically the delay between
cargo publish returning and the index being updated is less than the the time it takes to type
cd other_crate && cargo build. However, if you are publishing multiple dependent crates from a script, you may need to add a
sleep or retry behavior to account for the delay. Typically if you wait a second and re-run the command, it will succeed.
Note that in the case of a network issue the delay might be higher than usual. If GitHub or our hosting service are experiencing an outage, it might be minutes or longer. We’re still tuning the retry behavior, so in the event of a spurious issue you may see longer delays in the short term. However, when everything is running smoothly, you should not see a delay longer than 1 second on average and 5 seconds maximum. We’re planning to expose more of this information through the UI in the next few weeks.
Our system is configured to page whoever is on call if a crate goes too long without updating the index. However, if you’re having a problem after publishing or yanking a crate, please don’t hesitate to email email@example.com
If you have any questions, feel free to ask here or email firstname.lastname@example.org