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

fix(registry): make sure to process a download after it has completed #14680

Closed
wants to merge 1 commit into from

Conversation

x-hgg-x
Copy link
Contributor

@x-hgg-x x-hgg-x commented Oct 12, 2024

What does this PR try to resolve?

This PR solves the bug found in Eh2406/pubgrub-crates-benchmark#6 (comment).

With this PR we can avoid refetching the same dependency multiple times because a finished download was not processed before returning from the block_until_ready() method. It also improves the resolving speed since activate_deps_loop() is called less times overall.

@rustbot
Copy link
Collaborator

rustbot commented Oct 12, 2024

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added A-registries Area: registries A-sparse-registry Area: http sparse registries S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 12, 2024
@Eh2406
Copy link
Contributor

Eh2406 commented Oct 14, 2024

I've never had a deep grasp of the semantics of the curl crate. So I'm not going to take lead on reviewing this PR.

@arlosi
Copy link
Contributor

arlosi commented Oct 15, 2024

@x-hgg-x thanks for reporting and creating this fix!

I did some additional investigation and added additional testing in this area in a new PR #14694.

@x-hgg-x
Copy link
Contributor Author

x-hgg-x commented Oct 15, 2024

Closed in favor of #14694.

@x-hgg-x x-hgg-x closed this Oct 15, 2024
@x-hgg-x x-hgg-x deleted the fix-source-fetch branch October 15, 2024 19:15
bors added a commit that referenced this pull request Oct 15, 2024
fix(registry): `HttpRegistry` `block_until_ready` returns early when work is still pending

### What does this PR try to resolve?

`block_until_ready` is returning early when there are still pending transfers. This leads to extra restarts of the resolver, impacting performance.

In the existing implementation:
- `handle_completed_downloads` runs and there are no completed downloads
- `multi.perform()` is called and completes new downloads, with no pending transfers remaining
- Since there are no items `remaining_in_multi`, the function returns early

This fixes the issue by reordering the calls to `multi.perform()`, `handle_completed_downloads`, then the completion check.

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

A test is added that uses cargo's tracing to show the number of blocking calls. First commit shows existing behavior, second commit shows fix.

Originally based on the PR #14680 by `@x-hgg-x.` The ordering fix in this PR also avoids an additional `block_until_ready` call for retried failed downloads.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-registries Area: registries A-sparse-registry Area: http sparse registries S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants