Fix yarn berry missing portal:/link: copies (#1561)

[Mikola Lysenko (mikolalysenko)]

LLM Description written by Claude Code:claude-opus-5-5

Fixes #1561

Summary

A yarn berry portal: / link: dependency under another name ("lp2": "portal:./vend/lp") whose relative target can't be read is now treated as an unknown copy of any version of any package, the same as an absolute one (#1540). Hosted warns redirect_copy_unpatched, vendored warns vendor_copy_unpatched, and vex withholds every package that lock wires. Before this change the copy was dropped: scans reported success and VEX attested not_affected, while the install with the target present linked unpatched bytes as node_modules/lp2.

Root cause

Such a copy's lock version is the placeholder 0.0.0-use.local, so only its package.json says what it is. When reading that manifest yielded no identity, both the vendored/hosted copy finder (vendor/yarn_copies.rs other_name_copies) and VEX lockfile discovery (vex/discover/yarn.rs record_copies) treated "the read failed" the same as "read and found to hold no versioned package" (a link: to plain assets), and skipped the copy unless the path was absolute.

Fix

One shared predicate, yarn_copies::linked_copy_unknown, used by both callers. A linked copy is unknown when it is:

• never read (an absolute path, Yarn berry renamed-copy detection ignores a portal: / link: copy with an absolute path, so hosted and vendored scans succeed and every VEX path attests not_affected while that copy installs unpatched #1540),
• a missing target directory,
• an empty target directory (what git leaves for a submodule CI never checked out, the issue's main real-world trigger),
• a package.json that isn't a readable regular file, or isn't JSON (a Git LFS pointer, an encrypted blob).

It is not a package copy, and so stays ignored per the #1551 review intent, only when it is a non-empty directory with no package.json, or a parsed manifest naming no versioned package. CopyRef::is_unread_linked is folded into the predicate. The berry vendored warning keeps the "installs a package" wording for every unidentified linked copy. docs/ecosystems.md now spells out the missing / empty / LFS cases.

Tests (red → green)

Issue	Test	Red on main
#1561 vex (lock-only and in-run)	vex::discover::yarn::tests::issue_1561_unreadable_relative_portal_and_link_targets_contest_every_ref (portal/link × missing, empty, manifest-is-a-directory, LFS pointer)	yes, refs attested
#1561 vendored scan	vendor::yarn_berry_lock::tests::issue_1561_missing_relative_portal_and_link_targets_are_named (portal/link × missing, empty, LFS pointer; plain asset directory control stays unnamed)	yes, 0 vendor_copy_unpatched
#1561 hosted scan	hosted_memory_engine::issue_1561_berry_missing_relative_portal_and_link_copies_are_named (+ control: a target whose package.json names another package is not flagged)	yes, no redirect_copy_unpatched

The first commit (87d9321) holds only the tests, which failed on main as listed. The empty / lfs-pointer variants came from the pre-ready /code-review high pass.

Commands run locally (Linux, as root):

• cargo fmt --all -- --check: ok
• cargo clippy --workspace --all-features -- -D warnings: ok
• cargo test --workspace --all-features --no-fail-fast: 14,563 passed. The 10 failures are environment-only and touch no yarn code: write-failure / read-only-parent tests that can't fail when run as root (e.g. copy_tree::relax_loop_must_not_traverse_symlinked_root, pypi_requirements::wire_failure_rolls_back_already_written_files, repair_*, redirect_json_mode_write_failures_emit_error_envelope), and e2e_bun_lockb::binary_shared_bundled_record_hosted_pin_is_managed, which needs the live patch API (sandbox tunnel blocked). CI runs non-root with network.
• yarn-berry e2e with real yarn 4.18.0 (SOCKET_PATCH_YARN_E2E_REQUIRED=1): e2e_redirect_yarn_berry_build 37/37, e2e_vendor_yarn_berry_build 44/44, e2e_yarn4_pnpm_linker_build 40/40, e2e_yarn4_workspaces_build 39/39.
• Wrappers (npm/, pypi/, gem/) only dispatch to the binary and need no change.

/code-review high: findings not fixed

• Hosted in-memory scans and target files the host never sent. In memory mode, a relative linked copy is read only when the host includes its target's package.json in the snapshot (the new control test shows such a file is read and honoured). When the host leaves it out, the copy is now flagged as possibly unpatched instead of silently dropped. Dropping it was the fail-open this issue reports. Flagging matches how memory mode already treats an unread file: directory copy at its lock version (Yarn classic renamed-copy detection (#1489) misses a file: copy outside the project root and a tarball whose root isn't package/, so scans succeed and VEX attests while that copy installs unpatched #1516). Teaching path selection to fetch linked targets' manifests would mean parsing yarn.lock before the fetch, which is a separate change. Follow-up if wanted.
• other_name_copies probes with ProjectView::Disk (sync is_dir) rather than group-commit-aware helpers. The read beside it uses read_regular_to_bytes on the same disk path. No caller runs this inside an open group commit before the lock rewrite, and one stat per linked candidate is negligible. Left as is.

🤖 Generated with Claude Code

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 1018077. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Ready for review at 1018077.

• CI: 36/36 run checks green, 50 skipped by path filters (86 total); no main-wide failures.
• Bugbot: reviewed 1018077, no findings; no unresolved review threads.
• Mergeable against main, no CHANGELOG.md change.
• Worth a look: the shared yarn_copies::linked_copy_unknown predicate (which unreadable portal:/link: targets count as unknown copies vs. non-package directories).

Slack announcement not sent this run (Slack send unavailable); the next run retries.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does. A yarn berry portal: / link: dependency under another name with a relative target that can't be read (missing, an empty directory such as an unchecked-out submodule, or a package.json that isn't JSON, like a Git LFS pointer) is now treated as an unknown copy, the same as an absolute one (#1540). Hosted scans warn redirect_copy_unpatched, vendored scans warn vendor_copy_unpatched, and vex withholds every ref the lock wires. Before this, such copies were silently dropped, so vex could attest not_affected for a lock that installs unpatched bytes (#1561).

Risk: low. Fail-closed change in one predicate shared by two callers; the worst case is an extra warning, never a missed copy. A link: to a non-empty, manifest-less asset directory and a manifest naming another package both stay ignored, as before.

Look here

• yarn_copies.rs:143 linked_copy_unknown: the unknown vs. not-a-package rules.
• yarn_copies.rs:117 vendored/hosted caller.
• vex/discover/yarn.rs:901 VEX caller (now passes no lock version for any linked copy).
• hosted_memory_engine.rs:1966 hosted test plus the control case.

Verified

• Read the full diff (6 files, +291/-76). Paths: dir is the same base-joined, normalized path read_path already reads, absolute paths still short-circuit before any filesystem call, so no new path exposure. Forward-slash relative paths join fine on Windows.
• Tests cover portal/link × missing / empty / manifest-is-a-directory / LFS pointer, with a plain-directory control (vendored) and an other-package control (hosted). Ran cargo test -p socket-patch-core --lib issue_1561 locally: 2/2 pass.
• CI green on 1018077 (ci-ok, clippy and all run checks). Bugbot reviewed 1018077 with no findings, no open review threads, mergeable, CHANGELOG.md untouched.

Changes I made: none.

Open questions: none blocking. Known trade-off, written up in the PR description: in hosted in-memory mode a relative linked copy whose target files the host didn't send is now flagged rather than dropped (fail-closed, matching #1516).

Auto-merge is armed, so approving sends it straight to the merge queue.

---

Generated by Claude Code