Skip to content

fix(pm): serve chained crates from the cargo cache outside sync, and fix two workspace lookups - #392

Closed
fnzko wants to merge 0 commit into
symposium-dev:mainfrom
fnzko:crate-probe-cache-only
Closed

fnzko wants to merge 0 commit into
symposium-dev:mainfrom
fnzko:crate-probe-cache-only

Conversation

@fnzko

@fnzko fnzko commented Oct 26, 2026 •

Copy link
Copy Markdown
Contributor

What does this PR do?

Part of #413.

With the default recommendations registry, a workspace depending on anyhow or thiserror chains to error-battery-pack, and every hook event and --help ran cargo fetch and cargo metadata for it without --offline (0.26s instead of 0.05s per event offline, seconds online). A [plugins] use entry for a non-dependency did the same. Two smaller bugs sit in the same code: crate-info <member> returned an unrelated crates.io crate, and sync, status and use said "not in a Rust workspace" when cargo metadata failed on a broken Cargo.toml.

One commit each: under UpdateLevel::None a crate that is not a workspace dependency is read only from $CARGO_HOME/registry/src (sync and crate-info pass Check and still download); workspace members are recorded as member_crates and crate-info answers from them; a failed cargo metadata keeps cargo's error, which require() reports while load() stays silent for hooks.

Verified with offline repros for each bug and a sync from an empty cargo home.

Take into account:

  • A chained or enabled crate never downloaded is absent from hooks and --help until the next sync (at the latest the next SessionStart).
  • Carry provenance through package-manager results #357 has a broader member lookup; if it lands second it can drop the crate_command.rs branch.
Disclosure questions

AI disclosure.

  • The AI tool authored large parts of the code

@fnzko fnzko added the bug Something isn't working label Oct 27, 2026
@fnzko fnzko added this to the v0.6.0 milestone Oct 27, 2026

@nikomatsakis nikomatsakis left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Codex found what it thinks is a bug (and pushed test commit b557d8ca):

I added cached_lookup_does_not_substitute_another_registry, which currently fails.

The test caches crates.io foo 1.0.0 and private-registry foo 1.9.0, then requests foo = "^1.0". The cache-only lookup returns the private package because it scans every registry cache and chooses the highest matching version without checking the source.

This means hook dispatch can load a different plugin from the one Cargo resolved during sync. Name and version alone don’t identify a package across registries.

Please preserve the resolved registry/source identity in the cache-only path and make this regression test pass.

@fnzko

fnzko commented Oct 27, 2026

Copy link
Copy Markdown
Contributor Author

Thanks! fixed at 88ae8bd

@nikomatsakis
nikomatsakis added this pull request to the merge queue Oct 29, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to a conflict with the base branch Oct 29, 2026
@fnzko
fnzko enabled auto-merge October 29, 2026 12:13
@fnzko fnzko closed this Oct 30, 2026
auto-merge was automatically disabled October 30, 2026 13:28

Pull request was closed

@fnzko
fnzko force-pushed the crate-probe-cache-only branch from 88ae8bd to db04c7b Compare October 30, 2026 13:28

This branch was previously deployed

1 inactive deployment
github-pages — db04c7b0 Deployed Oct 29, 2026 by github-merge-queue[bot] via deploy #143
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants