Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Hosted cargo scan run from a workspace member treats it as a lockless project, rewrites only the member, and breaks every build of the workspace while reporting success

Ouverte
  • Quelque chose ne va pas ?
#417 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
72/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
rust
Domaine
cli, devtools

Piste de recherche

Start at crates/socket-patch-core/src/patch/redirect/mod.rs:1062 and compare workspace handling with crates/socket-patch-core/src/vendor/cargo.rs:1506. Reproduce the issue from cargo_hosted_workspace_member_declaration_is_pinned in crates/socket-patch-cli/tests/e2e_redirect_cargo_shapes.rs using a member as --cwd. Done means hosted mode resolves the workspace root or refuses with no files written, with regression coverage for this case.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

agent:triaged bug bughunt pm:cargo priority:p2

[agent] Found by the scheduled Cargo bug-hunt routine (ledger #315).

Summary

Take a cargo workspace whose Cargo.lock lives at the root, and run socket-patch scan --mode hosted (or a bare scan) with --cwd pointing at a member directory. Hosted mode treats the member as a standalone lockless project, because there is no Cargo.lock beside it and its only dependency is the patched crate. So it:

  • adds registry = "socket-patch-<uuid>" to the member's Cargo.toml,
  • writes the [registries.socket-patch-<uuid>] block to the member's .cargo/config.toml,
  • leaves the workspace root's Cargo.lock untouched (rewrittenFiles is [".cargo/config.toml", "Cargo.toml"], both relative to the member),
  • exits 0 with redirected: 1 and no warnings.

The workspace is then broken whichever directory you build from:

  • From the workspace root, cargo doesn't read the member's .cargo/config.toml, so the manifest no longer parses: failed to parse manifest at …/direct/Cargo.toml … registry index was not found in any configuration: socket-patch-c1f90104-….
  • From the member, the root lock still pins crates.io, so cargo fetch --locked fails with cannot update the lock file …/Cargo.lock because --locked was passed.

Any other member that inherits the crate through [workspace.dependencies] stays unpatched as well.

Impact

A "successful" scan leaves a workspace that can't build at all from the root, and can't build --locked anywhere. A fresh checkout in CI fails, and so does any cargo build a developer runs from the workspace root. Running socket-patch from inside a crate directory of a monorepo is an easy mistake to make, and it produces no warning.

Repro

This uses the shape cargo_hosted_workspace_member_declaration_is_pinned from crates/socket-patch-cli/tests/e2e_redirect_cargo_shapes.rs, with the scan's --cwd set to <proj>/direct instead of <proj>. That's a one-line local change; everything else, including the wiremock patch API and the sparse registry, is unchanged.

proj/Cargo.toml          [workspace] members = ["inherits", "direct"]
                         [workspace.dependencies] cfg-if = "1.0.4"
proj/inherits/Cargo.toml cfg-if = { workspace = true }
proj/direct/Cargo.toml   cfg-if = "1.0.4"
proj/Cargo.lock          (generated at the root, cfg-if 1.0.4 from crates.io)

$ socket-patch scan --mode hosted --json --yes --cwd proj/direct --api-url <mock> --org test-org --api-token fake
  -> exit 0, redirect.redirected = 1, warnings = [], rewrittenFiles = [".cargo/config.toml", "Cargo.toml"]
$ git -C proj status --porcelain
  M direct/Cargo.toml          # cfg-if = { version = "1.0.4", registry = "socket-patch-c1f9…" }
  ?? direct/.cargo/config.toml # [registries.socket-patch-c1f9…] index = "sparse+…"
  (Cargo.lock unchanged)
$ (cd proj && cargo fetch --locked)
  error: failed to load manifest for workspace member `…/proj/direct`
  Caused by: registry index was not found in any configuration: `socket-patch-c1f90104-5a0c-4e7a-9c0d-1a2b3c4d5e01`
$ (cd proj/direct && cargo fetch --locked)
  error: cannot update the lock file …/proj/Cargo.lock because --locked was passed to prevent this

It reproduced on every run (4 of 4).

Expected vs actual

  • Expected: CLI_CONTRACT.md: "A workspace member that shares its root's lockfile is part of that root's project." Hosted mode should either resolve the workspace root (the directory holding the Cargo.lock that the member's [workspace] points to) and rewrite there, or refuse loudly with nothing written. Vendored mode already refuses this case with cargo_manifest_not_workspace_root ("run from the workspace root"). ecosystems.md's lockless rule ("with no Cargo.lock the graph is unknown, so only a project whose sole dependency is the patched crate is redirected") assumes the directory really has no lock. A member whose workspace root has one isn't lockless.
  • Actual: success, redirected: 1, and a workspace that no longer builds.

Matrix

OS cargo Lock Reproduces
Linux 1.93.1 (repo toolchain) v4 yes
Linux 1.97.0 (stable) v4 yes
macOS / Windows any any not run. The cause is in which directory the rewriter treats as the project root, which is OS-independent.

I didn't bisect it. It's present on main 2463257 (after #277).

Suspect code

  • crates/socket-patch-core/src/patch/redirect/mod.rs:1062 (rewrite_cargo): it plans against the candidate files of --cwd only, so with no Cargo.lock in files it takes the lockless path, even though the member's manifest is part of a workspace. That shows as a parent Cargo.toml with [workspace] listing it, or a package.workspace key.
  • There's no hosted counterpart to crates/socket-patch-core/src/vendor/cargo.rs:1506 (NOT_WORKSPACE_ROOT), the vendored-mode guard for this exact situation.

Related, but a different mode: #338 (agent mode run from a workspace member patches the wrong copy).

Langage dominant
Rust
Étoiles
8
Forks
0
Merge moyen
18 h 4 min
PR mergées (30 j)
70

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de SocketDev/socket-patch

Toutes les issues de SocketDev/socket-patch

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.