Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Tracking Issue for publish-timeout #11222

Open
2 tasks
epage opened this issue Oct 12, 2022 · 0 comments
Open
2 tasks

Tracking Issue for publish-timeout #11222

epage opened this issue Oct 12, 2022 · 0 comments
Labels
C-tracking-issue Category: A tracking issue for something unstable. Command-publish S-waiting-on-feedback Status: An implemented feature is waiting on community feedback for bugs or design concerns.

Comments

@epage
Copy link
Contributor

epage commented Oct 12, 2022 •
edited by weihanglo
Loading

Summary

RFC: N/A
Original issue: #9507
Implementation: #11230, #11062
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#publish-timeout

Controls the timeout between uploading the crate and being available in the index

Unresolved Issues

  • What name makes this clear?
  • What should this look like? Is this per-CLI run or across all CLI runs (ie arg vs config)? Is this across all registries or per registry? Should the registry itself have a say when we publish

Future Extensions

No response

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
@epage epage added Command-publish C-tracking-issue Category: A tracking issue for something unstable. labels Oct 12, 2022
This was referenced Oct 12, 2022
Merged
Closed
bors added a commit that referenced this issue Oct 27, 2022
@bors
Auto merge of #11062 - epage:wait, r=weihanglo
7e484fc 
fix(publish): Block until it is in index

Originally, crates.io would block on publish requests until the publish
was complete, giving `cargo publish` this behavior by extension.  When
crates.io switched to asynchronous publishing, this intermittently broke
people's workflows when publishing multiple crates.  I say interittent
because it usually works until it doesn't and it is unclear why to the
end user because it will be published by the time they check.  In the
end, callers tend to either put in timeouts (and pray), poll the
server's API, or use `crates-index` crate to poll the index.

This isn't sufficient because
- For any new interested party, this is a pit of failure they'll fall
  into
- crates-index has re-implemented index support incorrectly in the past,
  currently doesn't handle auth, doesn't support `git-cli`, etc.
- None of these previous options work if we were to implement
  workspace-publish support (#1169)
- The new sparse registry might increase the publish times, making the
  delay easier to hit manually
- The new sparse registry goes through CDNs so checking the server's API
  might not be sufficient
- Once the sparse registry is available, crates-index users will find
  out when the package is ready in git but it might not be ready through
  the sparse registry because of CDNs

So now `cargo` will block until it sees the package in the index.
- This is checking via the index instead of server APIs in case there
  are propagation delays.  This has the side effect of being noisy
  because of all of the "Updating index" messages.
- This blocks by default but there is an unstable `publish.timeout` config field that will disable blocking when set to 0.  See #11222 for stablization

Blocking is opt-out as that is the less error prone case for casual users while those doing larger integrations are also likely to do the testing needed to make more complicated scenarios work where blocking is disabled.

Right now we block after the publish.  An alternative would be to block until all dependencies are in the index which makes the blocking only happen when needed
- Blocking on dependencies can be imprecise to detect when to block vs propagate an error up
- This is the less error prone case for users.  For example I recently publish a crate in one tab and immediately switched to another tab to use it and this only worked because `cargo-release` blocked until it was ready to use

In reviewing this change, be sure to look at the individual commits
- The first makes it possible to write the tests for this
- The second adds a test that shows the current behavior
- The third updates the test to the expected behavior, showing all of this works

In addition to the publish tests:
- We want to maximize the nightly-to-stable time to collect feedback
- We will put this in TWiR's testing section to raise visibility

Fixes #9507
@weihanglo weihanglo changed the title Tracking Issue for publish-timeut Tracking Issue for publish-timeout Oct 30, 2022
@tbrezot tbrezot mentioned this issue Jan 23, 2023
Open
@ehuss ehuss added the S-waiting-on-feedback Status: An implemented feature is waiting on community feedback for bugs or design concerns. label Apr 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-tracking-issue Category: A tracking issue for something unstable. Command-publish S-waiting-on-feedback Status: An implemented feature is waiting on community feedback for bugs or design concerns.
Projects
Cargo Roadmap
Status: Unstable, baking
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ehuss @epage