socket fix (Poetry): an exact pin on a direct dependency blocks the fix of its transitive dependency, and the diagnostic wrongly says there is no upgrade path

Reproduce with the exact and control zips using the steps in the issue, and read the --debug output of the failing run. Search the source for the "no upgrade path through the dependency tree" message and for the code that adds a direct constraint on the vulnerable transitive package before running poetry lock. Done means the exact run either raises opentelemetry-sdk to 1.45.1 or names the blocking direct constraint and its required version, and the misleading diagnostic no longer appears.

Summary

socket fix reports GHSA-xcq7-p3pf-p88h on opentelemetry-api 1.36.0 (fixed in 1.45.1), pulled in by opentelemetry-sdk. When the project pins opentelemetry-sdk to an exact version ("1.36.0"), the fix fails: Coana only tries to raise the transitive opentelemetry-api, and never the direct dependency opentelemetry-sdk, which itself requires opentelemetry-api==1.36.0. Raising opentelemetry-sdk to 1.45.1 is a minor update and is the only way to fix the advisory.

This is one bug. The second zip is a control: same lock file, only the constraint differs ("^1.36.0"), and the same run succeeds, Poetry moving opentelemetry-sdk and opentelemetry-semantic-conventions along with opentelemetry-api. This shows that the exact pin is the only cause, and that the diagnostic printed in both cases ("no version of opentelemetry-semantic-conventions is compatible", "no upgrade path through the dependency tree") is wrong.

Environment

Attachments

• socket-poetry-pin-repro-exact.zip: pyproject.toml, poetry.lock
• socket-poetry-pin-repro-control.zip: pyproject.toml, poetry.lock

pyproject.toml (exact; control has opentelemetry-sdk = "^1.36.0"):

[tool.poetry]
name = "repro"
version = "0.1.0"
package-mode = false

[tool.poetry.dependencies]
python = ">=3.10,<4.0"
opentelemetry-sdk = "1.36.0"

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"

Both poetry.lock files were generated by poetry lock and contain the same versions: opentelemetry-api 1.36.0, opentelemetry-sdk 1.36.0, opentelemetry-semantic-conventions 0.57b0, importlib-metadata 8.7.1, typing-extensions 4.16.0, zipp 4.1.2 (poetry check --lock passes).

Steps to reproduce

for v in exact control; do
  d=socket-poetry-pin-repro-$v
  unzip -q "$d.zip" && cd "$d"
  git init -q && git add -A && git commit -qm repro   # only to see the diff afterwards
  socket fix . --all
  echo "$v: exit=$?"
  git --no-pager diff --stat
  cd ..
done

Expected

exact: opentelemetry-sdk is raised to 1.45.1 in pyproject.toml (a minor update, allowed even with --no-major-updates) and poetry.lock gets opentelemetry-api 1.45.1, opentelemetry-sdk 1.45.1 and opentelemetry-semantic-conventions 0.66b1. Exit code 0.

If raising a direct dependency is out of scope, the run should at least say which direct constraint blocks the fix and what it must be raised to (opentelemetry-sdk pinned to 1.36.0 in pyproject.toml, 1.45.1 required), instead of reporting that no upgrade path exists.

In both zips, the diagnostic should not claim that no version of opentelemetry-semantic-conventions is compatible with the patched opentelemetry-api.

Actual

Both zips print the same analysis first:

info: Unable to compute fixes for some vulnerabilities:
info: - GHSA-xcq7-p3pf-p88h:
info:   • pkg:pypi/[email protected]?artifact_id=tar-gz (via pkg:pypi/[email protected]?artifact_id=tar-gz -> pkg:pypi/[email protected]?artifact_id=tar-gz)
info:     ⚠ pkg:pypi/opentelemetry-api has safe versions (the lowest is 1.45.1), but no version of pkg:pypi/opentelemetry-semantic-conventions (installed 0.57b0) is compatible with them. There is no upgrade path through the dependency tree — applying this fix would require an override (e.g. pnpm overrides) forcing pkg:pypi/opentelemetry-semantic-conventions to accept a patched version of pkg:pypi/opentelemetry-api.
info: Upgrading purls for .../socket-poetry-pin-repro-<exact|control>:
        pkg:pypi/[email protected] → 1.45.1

exact (with --debug):

debug: Running command: poetry lock in .../socket-poetry-pin-repro-exact
debug: Poetry stderr
Because opentelemetry-sdk (1.36.0) depends on opentelemetry-api (1.36.0)
 and repro depends on opentelemetry-api (1.45.1), opentelemetry-sdk is forbidden.
So, because repro depends on opentelemetry-sdk (1.36.0), version solving failed.
debug: Running command: poetry lock in .../socket-poetry-pin-repro-exact
info: ❌ Poetry could not upgrade opentelemetry-api to 1.45.1: Because opentelemetry-sdk (1.36.0) depends on opentelemetry-api (1.36.0) ─ poetry.lock
debug: Error stack: UpgradePurlPartialError: Some workspaces failed to upgrade
0/1 workspaces were upgraded successfully.
Failed workspaces:
  - poetry.lock
✖  Coana command failed (exit code 3): command failed

Exit code 1. The working tree is left unchanged (the change is reverted correctly).

control:

info: ✅ Locked opentelemetry-api 1.45.1 ─ poetry.lock
info:    └─ pkg:pypi/[email protected] → 1.45.1
1/1 workspaces were upgraded successfully.
✔ Finished!

Exit code 0. Only poetry.lock changes: opentelemetry-api and opentelemetry-sdk 1.36.0 to 1.45.1, opentelemetry-semantic-conventions 0.57b0 to 0.66b1 (importlib-metadata and zipp are dropped). pyproject.toml is unchanged and poetry check --lock passes.

Analysis

• Poetry's error shows the strategy: a direct constraint repro depends on opentelemetry-api (1.45.1) is added for the vulnerable transitive package, then poetry lock is run. With opentelemetry-sdk = "1.36.0" in the root, which requires opentelemetry-api==1.36.0, this cannot be solved. The blocking constraint is a direct dependency declared in the user's own pyproject.toml, and raising it within the same major version is enough, but this is never attempted.
• The control run proves that an upgrade path exists: opentelemetry-semantic-conventions 0.66b1 accepts opentelemetry-api 1.45.1, and Poetry picks it. The analysis appears to only consider the installed version of the intermediate packages (installed 0.57b0), not newer ones.
• The same advisory is listed under "Unable to compute fixes" and then fixed successfully in control, which makes the output contradictory.
• The suggested remedy ("an override (e.g. pnpm overrides)") does not apply to Poetry, which has no override mechanism.

Real-world impact

OpenTelemetry Python packages require exact versions of each other (opentelemetry-sdk 1.36.0 requires opentelemetry-api==1.36.0, opentelemetry-semantic-conventions==0.57b0), so applications commonly pin the whole family to exact versions to keep it consistent. On our project, five OpenTelemetry packages are pinned this way (opentelemetry-api, opentelemetry-sdk, opentelemetry-exporter-otlp at 1.36.0; opentelemetry-distro, opentelemetry-instrumentation-fastapi at 0.57b0). socket fix . --all --no-major-updates --ecosystems pypi --package-managers poetry fails exactly as in the exact zip. The fix had to be applied by hand: raise the whole family to 1.45.1 / 0.66b1, then poetry lock; the test suite passes.

Suggested fix

When a transitive upgrade is blocked by the constraint of a direct dependency in the manifest, raise that direct dependency to the lowest version that accepts the patched transitive version (here opentelemetry-sdk 1.45.1), within the limits of --no-major-updates.