Vendored Poetry never re-vendors to a superseding patch: re-scan exits 1 with pypi_poetry_source_already_exists, while --dry-run previews would_revendor, and the project keeps installing the old patch #1136

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

Summary

A Poetry project vendored with patch uuid A can't move to a newer patch uuid B for the same name@version. When the patch API supersedes A with B, scan --mode vendored (and get <B> --mode vendored) downloads B (download.patches[].oldUuid = A, updates: [{oldUuid: A, newUuid: B}]), then the vendor step fails with:

failed  pkg:pypi/six@1.16.0?artifact_id=py2-py3-none-any-whl  pypi_poetry_source_already_exists
"poetry.lock already routes six through .socket/vendor/pypi/<A> (an earlier socket-patch vendor); run `socket-patch vendor --revert` for it and re-vendor"

The run ends status: partial_failure, exit 1. poetry.lock stays wired to .socket/vendor/pypi/<A>/…, so every poetry install keeps installing the old patch. The same run's --dry-run previews action: "would_revendor" (+ oldUuid), status success, exit 0.

#943 fixed this for uv, script locks and Hatch (#742, #650); #825 fixed it for Pipenv and #766 for requirements.txt. The Poetry arm of the vendored orchestrator was left out.

Impact

• A superseding patch (for example a fixed patch, or one covering more advisories) never reaches vendored Poetry projects. Every scheduled scan --mode vendored in CI fails with exit 1 until someone intervenes by hand.
• The error tells the user to revert a wiring that socket-patch wrote itself. Following that advice isn't enough: when the project venv still holds the old patch's bytes, the re-scan after vendor --revert fails again with package_not_installed ("no installed package found on disk", exit 1), and the lock is left with no patch at all. The working sequence is vendor --revert, then poetry install (pristine bytes back), then scan --mode vendored. That second failure is the class uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 tracks for uv.
• The dry run promises a re-vendor the wet run refuses.

Repro (Linux, real Poetry, local mock patch API)

The mock answers POST …/patches/{batch,package}, GET …/by-package/…, GET …/view/<uuid> and serves a deterministic patched six-1.16.0-py2.py3-none-any.whl (sha256 + sha512 in the grant). It first offers uuid A (3c5e7a9b-…, six.SOCKET_PATCHED = 1), then switches to offer only uuid B (5e7a9c1d-…, SOCKET_PATCHED = 2) for pkg:pypi/six@1.16.0.

cat > pyproject.toml <<'EOF'
[tool.poetry]
name = "demo"
version = "0.1.0"
description = ""
authors = ["x <x@example.com>"]
[tool.poetry.dependencies]
python = "^3.9"
six = "1.16.0"
EOF
printf '[virtualenvs]\nin-project = true\n' > poetry.toml
poetry lock
SP="--api-url $M --org o --api-token x --json --ecosystems pypi"
socket-patch scan --mode vendored $SP            # uuid A vendored, exit 0
# patch API now offers only uuid B
socket-patch scan --mode vendored $SP --dry-run  # vendor.events: would_revendor (oldUuid A), exit 0
socket-patch scan --mode vendored $SP            # exit 1, partial_failure, pypi_poetry_source_already_exists
grep -o 'vendor/pypi/[0-9a-f]\{8\}' poetry.lock  # still 3c5e7a9b (A)
rm -rf .venv && poetry install --no-root
.venv/bin/python -c 'import six; print(six.SOCKET_PATCHED)'   # 1 (old patch)

Expected vs actual

• Expected (crates/socket-patch-cli/CLI_CONTRACT.md, scan --vendor paragraph): "A package the ledger holds at an older patch uuid is still re-vendored automatically when discovery selects the newer patch (its old uuid dir is removed — vendor_stale_artifact_removed)". The same paragraph says --dry-run would_revendor previews that re-vendor.
• Actual: the wet run refuses with exit 1 and keeps uuid A wired. The dry run and the wet run disagree.

Matrix (Linux, main 3b4ac84)

Each failing cell reproduced on two separate runs. The behaviour comes from the lock writer, not from Poetry or the OS. Not bisected: the refusal has been in check_target_guards since vendored Poetry support landed. #943 is where the sibling flavors gained the replay path.

Suspect code

• crates/socket-patch-core/src/vendor/pypi.rs:926-946: the PypiFlavor::Poetry arm maps every check_target_guards error straight to refused(..). The uv, script-lock and Hatch arms (pypi.rs:867/887/910) route the same "our own older wiring" refusal through supersede_or_refuse (pypi.rs:1586), and superseded_files (pypi.rs:1666) has no Poetry entry.
• crates/socket-patch-core/src/vendor/pypi_poetry.rs:243-257: the "Ours, but a STALE patch generation" branch refuses with pypi_poetry_source_already_exists instead of letting the orchestrator replay the recorded entry's revert and wire uuid B.
• The unit test splice_flavor_stale_uuid_vendor_refuses_through_orchestrator (pypi.rs:7462) pins the refusal for poetry.lock, which contradicts the contract.
• The PDM arm (pypi.rs:948) looks the same; I've handed that over to the PDM routine rather than folding it in here.

No probe runs: macOS and Windows probe branches are blocked for this routine (see ledger #311). The defect is platform-independent code.