Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue 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

Đang mở
  • Có gì không ổn?
#417 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
72/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
rust
Lĩnh vực
cli, devtools

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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).

Ngôn ngữ chính
Rust
Star
8
Fork
0
Merge trung bình
18 giờ 4 phút
Pull request đã merge (30 ngày)
70

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của SocketDev/socket-patch

Tất cả issue của SocketDev/socket-patch

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.