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.

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

Cargo publish times out without failure #11616

Open
tbrezot opened this issue Jan 23, 2023 · 13 comments
Open

Cargo publish times out without failure #11616

tbrezot opened this issue Jan 23, 2023 · 13 comments
Labels
A-diagnostics Area: Error and warning messages generated by Cargo itself. A-documenting-cargo-itself Area: Cargo's documentation C-bug Category: bug Command-publish E-easy Experience: Easy S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review

Comments

@tbrezot
Copy link

tbrezot commented Jan 23, 2023

Problem

When trying to publish a crate, we recently experienced an issue reported here. The command cargo publish timed out without returning an error.

Steps

This may be not repeatable without hacking the cargo publish network communication. Our guess is that the crates.io server is currently experiencing some issue.

There is the GitHub CI recipe that failed (problem occurs on the cargo publish --token $CRATES_IO part):

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - name: Dump context for debug
        uses: crazy-max/ghaction-dump-context@v1

      - uses: actions/checkout@v1

      - name: Publishing - dry run
        if: inputs.publish == false
        run: |
          cargo publish --dry-run
      - name: Publishing
        if: inputs.publish == true
        run: |
          echo "[registry]" > ~/.cargo/credentials
          echo "token = \"$CRATES_IO\"" >> ~/.cargo/credentials
          cargo publish --token $CRATES_IO
        env:
          CRATES_IO: ${{ secrets.CRATES_IO }}

      - name: Release
        if: inputs.publish == true
        uses: softprops/action-gh-release@v1

Below is the screenshot of a local attempt to run cargo publish --allow-dirty.

image

Possible Solution(s)

Return with an error upon time out.

Notes

No response

Version

cargo 1.68.0-nightly (985d561f0 2023-01-20)
release: 1.68.0-nightly
commit-hash: 985d561f0bb9b76ec043a2b12511790ec7a2b954
commit-date: 2023-01-20
host: x86_64-unknown-linux-gnu
libgit2: 1.5.1 (sys:0.16.1 vendored)
libcurl: 7.86.0-DEV (sys:0.4.59+curl-7.86.0 vendored ssl:OpenSSL/1.1.1q)
os: Ubuntu 22.10 (kinetic) [64-bit]
@tbrezot tbrezot added the C-bug Category: bug label Jan 23, 2023
@tbrezot
Copy link
Author

tbrezot commented Jan 23, 2023

#11222

@Turbo87
Copy link
Member

Turbo87 commented Jan 23, 2023

somewhat off-topic, but if you use something like https://github.com/glide-rs/flarmnet-rs/blob/1aa7363ace21096fa5fd3107207d0c03c0be984f/.github/workflows/release.yml#L17-L19 you don't have to use --token :)

@epage
Copy link
Contributor

epage commented Jan 23, 2023

Huh, I didn't document this behavior in #11062.

This was an intentional choice. We were transitioning from no timeout to a timeout and were concerned about the impact for existing users (ie not dependent on blocking, single crate) when sporadic, issues like Github being down, occur and (1) didn't want the timeout to be too long and (2) didn't want it to be an error when it wasn't before.

Now, whether we have a path to later turning this into an error is a different question. We were especially worried about the impact of this behavior change on alternative registeries and had #11222 as an escape hatch but we haven't yet seen a need or even interest in it or problem with blocking.

@weihanglo
Copy link
Member

The situation has been improved since then. We have more HTTP info and a better block-wait notice when publishing.

To resolve this issue, the missing piece should be adding a simple sentence mentioning in cargo-publish man page, such as a simplified version of what #11926 did.

@weihanglo weihanglo added A-documenting-cargo-itself Area: Cargo's documentation S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review labels Apr 25, 2023
@weihanglo weihanglo added the E-easy Experience: Easy label May 27, 2023
@epage
Copy link
Contributor

epage commented Sep 25, 2023

@weihanglo while documenting helps, I think the core of this issue is about making it an error or am I missing something?

bors added a commit that referenced this issue Sep 25, 2023
…=epage

docs: warn about upload timeout

### What does this PR try to resolve?

Adds documentation missing from #11062 as noticed in #11616

### How should we test and review this PR?

editor review
@weihanglo
Copy link
Member

@weihanglo while documenting helps, I think the core of this issue is about making it an error or am I missing something?

I was thinking that it may break somebody's workflow. But since it already timed out, turning this into a hard error makes more sense than no error. What do people think?

@weihanglo weihanglo added the A-diagnostics Area: Error and warning messages generated by Cargo itself. label Sep 26, 2023
@Rustin170506
Copy link
Member

What do people think?

It makes more sense to me.

@epage
Copy link
Contributor

epage commented Sep 26, 2023

More so I meant that we need to make sure we decide on the merit and timing of a hard error for closing this rather than closing this for documentation.

@after-ephemera
Copy link

I am admittedly not familiar with all of the implications of erroring out in this situation, but it seems appropriate given that the command's explicit intent (publish the crate) didn't succeed. I can't think of a use case where I would issue the publish command, manually or in automation, and find a failure acceptable. @epage I'd love your thoughts before digging deeper into this.

@epage
Copy link
Contributor

epage commented Jan 8, 2024

@after-ephemera the publish endpoint reported success. However, the publish process is asynchronous to that. So the reasons someone will see a timeout are (1) there is some kind of service outage blip or (2) the rest of the publish pipeline failed. I'm assuming a failure in the publish pipeline would generally be considered a bug, be rare,and be actively monitored for by the crates.io team. I and others have seen service blips.

So timeout, doesn't mean the publish failed and more than likely it succeeded.

@after-ephemera
Copy link

Ah so there's a bit more nuance here, thank you for explaining it. When you say "service blips" are you referring to network connectivity issues that are intermittent? If so, I would venture a guess that it's fine to leave as is since either that or pipeline issues are expected to be rare and intermittent.

@epage
Copy link
Contributor

epage commented Jan 8, 2024

Basically, yes.

@progressive-galib
Copy link

then should we close this issue ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Error and warning messages generated by Cargo itself. A-documenting-cargo-itself Area: Cargo's documentation C-bug Category: bug Command-publish E-easy Experience: Easy S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review
Projects
None yet
Development

No branches or pull requests

7 participants