Repository navigation
VEX product detection fails on Poetry 2 projects that declare dynamic = ["version"] with the version in [tool.poetry], so scan --vex exits 1 after rewriting poetry.lock #1527
Description
[agent] Found by the scheduled Poetry bug-hunt routine (ledger #311).
Summary
Poetry 2 documents a PEP 621 layout where [project] has name and dynamic = ["version"], and the version is in [tool.poetry] version (see https://python-poetry.org/docs/pyproject/#version). poetry check, poetry version and poetry build all accept it (demo 0.3.0, demo-0.3.0-py3-none-any.whl).
vex/product.rs::parse_pyproject reads name and version from one section only. It tries [project], which has no version, and then [tool.poetry], which has no name. Both return None, so no product is detected:
socket-patch vex -O out.jsonexits 2 withproduct_undetected("pyproject.toml was found but has no usable name and version").socket-patch scan --mode hosted --vex out.jsonexits 1 withproduct_undetected, after it has already rewrittenpoetry.lockto the hosted pin. No VEX document is written.
This happens whenever the product falls through to the manifest probe, which means a checkout with no git origin remote (for example a source tarball or an exported tree). A git remote takes priority in detect_product.
This isn't the same as #642. That issue is about a missing [tool.pdm] fallback. Here both sections are read, but their keys are never combined.
Impact
- Any Poetry 2 project that uses the documented dynamic-version layout gets no VEX unless the user passes
--productby hand, andscan --vexturns a successful hosted rewrite into a failed command (exit 1) in CI. - The lock rewrite is still committed, so a retry without
--vexhas nothing left to do, and the failure looks like a broken scan.
Repro (Linux, Poetry 2.0.1 / 2.2.1 / 2.5.1, no git checkout)
A local mock of the patch API serves a hosted patch for pkg:pypi/six@1.16.0 (same routes as crates/socket-patch-cli/tests/in_process_redirect_poetry.rs). Any patched dependency would do.
mkdir demo-proj && cd demo-proj && mkdir demo && touch demo/__init__.py
cat > pyproject.toml <<'EOF'
[project]
name = "demo"
dynamic = ["version"]
requires-python = ">=3.9"
dependencies = ["six==1.16.0"]
[tool.poetry]
version = "0.3.0"
[build-system]
requires = ["poetry-core>=2.0.0"]
build-backend = "poetry.core.masonry.api"
EOF
poetry check # All set!
poetry version # demo 0.3.0
poetry lock
socket-patch scan --mode hosted --json --vex out.vex.json
# exit 1, status "error", error.code "product_undetected"
# poetry.lock now carries the hosted pin; out.vex.json not written
socket-patch vex -O v.json # exit 2, product_undetected
socket-patch vex -O v.json --product pkg:pypi/demo@0.3.0 # exit 0 (workaround)Control: with version = "0.3.0" in [project] (no dynamic, no [tool.poetry]), scan --mode hosted --vex exits 0 and the product is pkg:pypi/demo@0.3.0.
Expected vs actual
- Expected:
vex --helpdocuments auto-detection from "pyproject.toml: pkg:pypi/@". For a project Poetry itself builds asdemo 0.3.0, the product should bepkg:pypi/demo@0.3.0:[project].name, plus the[tool.poetry].versionthat Poetry uses whenversionis listed in[project].dynamic. CLI_CONTRACT.md ("Fail-the-command") saysscan --vexexits non-zero when the product is undetectable, but here it can be detected. - Actual:
product_undetected.vexexits 2, andscan --vexexits 1 after it has written the lock.
OS × version
| OS | Poetry | Result |
|---|---|---|
| Linux | 2.0.1 | fail (2/2) |
| Linux | 2.2.1 | fail |
| Linux | 2.5.1 | fail (2/2) |
| Linux | 2.5.1, static [project].version (control) |
pass |
| macOS / Windows | any | untested. The code path doesn't depend on the OS (pure TOML text scan). |
Poetry 1.x ignores [project], so the layout only applies to Poetry ≥ 2.0.
Suspect code
crates/socket-patch-core/src/vex/product.rs:157-165(parse_pyproject):scan_toml_section(content, "project").or_else(|| scan_toml_section(content, "tool.poetry"))needs both keys from the same section. When[project]has anameanddynamiccontains"version", it should take the version from[tool.poetry].crates/socket-patch-core/src/vex/product.rs:368(scan_toml_section) returns nothing unless both keys are present.
Main 6a06ddd. No probe runs: probe branches are still blocked for this routine (see ledger #311).
Activity
poetry: run 21 ledger (#1527, #1503 verified fixed)
mikolalysenko commentedon Oct 14, 2026
[agent] Triage:
priority:p1(Poetry, PyPI family). Not a duplicate: #642 is a different symptom (PDM 0.x[tool.pdm]), and no open or merged PR covers it. Confirmed on maina8da202:parse_pyproject(crates/socket-patch-core/src/vex/product.rs:157) callsscan_toml_section("project").or_else(|| scan_toml_section("tool.poetry")), and each call needs both keys from its own table.Shares root cause with #642:
vex/product.rs::parse_pyprojecttakesnameandversionfrom one table only ([project], else[tool.poetry]), so it never combines[project].namewith a dynamic version kept in[tool.poetry]and never reads the legacy[tool.pdm]table. Will be fixed together. Thescan --vexwrite-before-product ordering both reports mention is tracked separately in #1064.Generated by Claude Code
mikolalysenko commentedon Oct 14, 2026
[agent] Claiming this issue (with #642; shared root cause: pyproject product detection reads name and version from a single table). Branch: agent/fix-pyproject-product-tables. Claim-ID: 2026-10-14T10:21:23Z-28fe92
Generated by Claude Code
mikolalysenko commentedon Oct 14, 2026
[agent] Draft PR: #1529
Generated by Claude Code
Detect Poetry 2 and PDM 0.x pyproject products