Goal

Replace the hard == pin on langchain-tests in libs/langchain-mongodb/pyproject.toml with a range, so it stops propagating its own transitive requirements as hard floors into every resolution in the project.

Blocked by

Nothing. Related to INTPYTHON-1065 (which this caused) and INTPYTHON-1066 (which exposed it).

Background — why this matters beyond style

langchain-tests==1.1.9 sits in the dev dependency group, which is a uv default group, so it is installed in every developer and CI environment. It requires langchain-core<2.0.0,>=1.4.0.

Because the pin is exact, that >=1.4.0 becomes an unconditional floor on langchain-core for the whole project. The practical effect, discovered under INTPYTHON-1065:

• langchain-mongodb declared langchain-core>=1.2.5 as a runtime dependency.
• No dev or CI environment could ever resolve below 1.4.0, so the minimum-version job installed 1.4.0 — never 1.2.5.
• Users installing from PyPI get no dev group, so >=1.2.5 genuinely was permitted for them, and nothing had ever tested it.

The declared runtime floor was therefore an untested claim made to users, and the dev-group pin was structurally preventing CI from ever catching that. INTPYTHON-1065 raised the runtime floor to 1.4.2 to make the declaration honest, but the underlying clamp is still there and will do the same thing to the next dependency.

Current state (verified on main)

Repo	Specifier
langchain-mongodb	langchain-tests==1.1.9
langchain-postgres	langchain-tests>=1.1.5
langchain-google (genai)	langchain-tests>=1.1.4,<2.0.0
langchain-aws	langchain-tests>=1.1.3

The hard pin is local to this repo, not a LangChain convention. It was introduced already-pinned in commit 0a2eea2 ("INTPYTHON-434 Add standard test suites for Vector Store and Tools", Mar 2025) as langchain-tests==0.3.14, with no comment giving a rationale, and INTPYTHON-434 contains no discussion of version strategy. Since then it has been bumped purely mechanically by dependabot: 1.1.0 → 1.1.1 → 1.1.4 → 1.1.5 → 1.1.6 → 1.1.9.

The argument for keeping a pin, and why a range still works

langchain-tests is not a normal test dependency — it ships the test suite itself. These classes inherit from it:

• tests/unit_tests/test_tools.py — 4 classes extending ToolsUnitTests
• tests/integration_tests/test_tools.py — 4 classes extending ToolsIntegrationTests
• tests/integration_tests/test_vectorstore_standard.py — VectorStoreIntegrationTests
• tests/integration_tests/test_retrievers_standard.py — 2 classes extending RetrieversIntegrationTests

A new minor release can add new required test methods, turning CI red without any change on our side. That is a real risk and the likely original motivation.

But the pin does not actually prevent it — dependabot bumps the pin promptly (10 releases in the 1.1.x line since Dec 2025), so the churn arrives anyway, just as a PR. A bounded range keeps the protection against surprise minor bumps while removing the unconditional clamp.

Proposed change

"langchain-tests>=1.1.9,<1.2",

Matching the pattern the sibling partner repos already use. Exact bound open to discussion — langchain-google uses <2.0.0, which is looser.

Steps

1. Change the specifier and regenerate uv.lock.
2. Confirm the standard-test subclasses listed above still pass — they are the only consumers.
3. Re-check what langchain-core resolves to under uv sync --resolution=lowest-direct; the point of the change is that it should now be able to reach the declared runtime floor rather than being clamped to 1.4.0+.
4. If it can, consider whether INTPYTHON-1065's runtime floor of langchain-core>=1.4.2 should be re-examined, since it would then be genuinely testable rather than merely declared.

Acceptance criteria

• langchain-tests is specified as a range, not ==.
• Unit and integration suites pass, including all standard-test subclasses.
• uv sync --resolution=lowest-direct resolves langchain-core to the declared runtime floor rather than to a value clamped by the dev group — verifiable from the uv pip list output added in INTPYTHON-1066.

Notes

• This was chosen in preference to building a separate "runtime floors only" CI job. That alternative was prototyped: uv sync --resolution=lowest-direct --no-default-groups does correctly install runtime dependencies at their declared floors, but the unit suite cannot run in that environment (addopts requires syrupy; tests import freezegun, pytest-mock and langchain-tests). It degrades to an import smoke test, and the package was verified to import cleanly at langchain-core==1.2.5 — so such a job would not have caught the bug that motivated it. Removing the clamp at its source is both cheaper and more effective.