Skip to content

[Bug]: the Stage 2C hash lock still pins mcp 1.28.1 after the 1.30.0 security bump, failing the required dependency-lock gate #6746

Closed

Description

@JasonBuildAI

Preflight

  • I searched existing issues and discussions for this behavior.
  • This report is not an unpatched security vulnerability. The cited advisory is public and already fixed in the declared version; this report is about the lock that still installs the superseded version.
  • The report and attachments contain no credentials or private/internal material.

Issue origin

  • Observed or reproduced in a real environment

LoopX version or commit

f9bdae67596c185cebc81dc555dd6a3e0242e9c5 (reproduced); still present on dffede5af0d8e6c282bff9ff439b0fb1061e2c33.

Host or runtime surface

  • Not host-specific

LoopX area

  • Build, packaging, installer, or CI

Problem

The required Python Tests job fails on the Stage 2C dependency-lock gate for every code PR, and the Stage 2C environment still installs the superseded mcp.

tests/test_stage2c_dependency_lock.py checks that the hash lock used by the Stage 2C lane satisfies every dependency declared by pyproject.toml. PR #6600 (commit 05a59910c, merged 2026-10-17) raised the declared mcp pin from 1.28.1 to 1.30.0, but tests/requirements-stage2c-linux-py311.txt still pins mcp==1.28.1. The gate therefore fails with Stage 2C pin mcp==1.28.1 does not satisfy mcp==1.30.0 in whichever required test-shard job carries it, which turns the required pytest job and merge-gate red for code PRs and keeps the scheduled full main qualification red.

The same drift means the Stage 2C lane installs mcp 1.28.1 while the declaration asks for 1.30.0. 1.30.0 is the release that fixes the published unbounded-session-memory advisory GHSA-84m7-p3x7-pcfv (CVE-2026-59951, affected 1.8.0 through 1.29.1), so the security bump is not exercised by the lane that installs this lock.

Scope: this is the Stage 2C test environment. Production dependencies, workflow selection, and acceptance thresholds are unchanged. Precedent: #6142 repaired the same lock/declaration drift while adding the current regression gate.

Minimal reproduction

git checkout f9bdae675
uv sync --extra test --python 3.11
uv run --extra test python -m pytest -q tests/test_stage2c_dependency_lock.py

Expected behavior

The hash lock satisfies every declared requirement, tests/test_stage2c_dependency_lock.py passes, and the Stage 2C environment installs the declared mcp==1.30.0.

Actual behavior

AssertionError: Stage 2C pin mcp==1.28.1 does not satisfy mcp==1.30.0
assert False
 +  where False = contains('1.28.1', prereleases=True)
 +    where contains = <SpecifierSet('==1.30.0')>.contains
1 failed in 3.69s

Sanitized diagnostics

  • Local host: native Windows, Python 3.11.14, focused run of tests/test_stage2c_dependency_lock.py (1 failed).
  • Matching CI failure in the scheduled full qualification run 38978329284 (test-shard (1)), which reported 7 failed, 3969 passed; this gate is one of the seven (the others are the lease-contract alignment already repaired by bcb67a8de/138f27871).
  • The lock header records its generator and target: uv 0.11.26, uv pip compile pyproject.toml tests/requirements-stage2c-tools.in --extra test --python-version 3.11 --python-platform x86_64-unknown-linux-gnu --generate-hashes.
  • pyproject.toml declares mcp==1.30.0 in the test, ego-source-reader, and public-source-reader extras; tests/requirements-stage2c-linux-py311.txt pins mcp==1.28.1.
  • mcp 1.30.0 has the same requires_dist as 1.28.1 and all of its constraints are already satisfied by the existing lock pins, so the expected regeneration changes only the mcp entry.

Additional context

Activity

  1. JasonBuildAI commented on Oct 17, 2026

    @JasonBuildAI
    ContributorAuthor

    Closing as resolved on main: PR #6730 (merged 2026-10-17, commit dffede5) now carries the Stage 2C mcp pin at 1.30.0 with the published wheel/sdist hashes. Re-verified at dffede5: \ ests/test_stage2c_dependency_lock.py\ passes (1 passed), so the required gate no longer fails on this drift. No separate repair is needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions