Repository navigation
requirements-ci/langchain.txt's langchain-core pin is one release behind production #16638
Description
Found during #16636's review (the dependabot-train reconciliation base fix).
`requirements-ci/langchain.txt:5` declares `langchain-core>=1.6.1,<2.0.0`, but `autobot-backend/requirements.txt:78` and `autobot-infrastructure/shared/docker/ai-stack/requirements-ai.txt:6` both declare `langchain-core>=1.6.2,<2.0.0` (bumped by the dependabot train's #16572 member).
This is invisible to both of #16636's fixed checks:
- `repo_tests/ansible_requirements_parity_test.py` compares ansible's floor against the union of all manifests' text, and `1.6.2` is present in that union (from the other two files), so the union-membership check passes regardless of `langchain.txt`'s own stale value.
- `pipeline-scripts/check_dependency_floors.py --strict` checks CI-installed versions satisfy declared floors; `langchain.txt`'s `>=1.6.1` is itself a floor declaration, not a checked-against value, so an older floor there doesn't fail the strict check either.
Not gating anything currently, but the CI-installed `langchain-core` version could still resolve below `1.6.2` in a fresh install, silently diverging from what production declares. Fix: bump `requirements-ci/langchain.txt:5` to `langchain-core>=1.6.2,<2.0.0` to match.
Activity
mrveiss commentedon Oct 3, 2026
Closing — the divergence this issue reports is gone, and all three declarations now agree.
The issue states
requirements-ci/langchain.txt:5declared>=1.6.1while the other two manifests declared>=1.6.2, and names one fix: bump the CI floor. Onorigin/main, comments stripped so a version quoted in explanatory prose cannot be mistaken for a declaration:requirements-ci/langchain.txtlangchain-core>=1.6.5,<2.0.0autobot-backend/requirements.txtlangchain-core>=1.6.5,<2.0.0autobot-infrastructure/shared/docker/ai-stack/requirements-ai.txtlangchain-core>=1.6.5,<2.0.0All three moved past the reported pair and landed together, so the stated risk — "the CI-installed
langchain-coreversion could still resolve below 1.6.2 in a fresh install, silently diverging from what production declares" — no longer applies.Worth recording how nearly I got this wrong. My first read grepped
langchain-core[>=<0-9.,]*and took the first hit per file, which returned>=1.4.0,>=1.4.7and>=1.6.5— three different floors and an apparent live divergence. Those first two hits are inside comments explaining earlier bumps. The files document their own history, so a pattern that does not strip comments reads the history as the state. Stripping#to end-of-line first gives the three identical values above.That is this issue's own subject one level up: it exists because two checks compared the wrong thing — a union-membership test that passes when any manifest carries the value, and a strict check that treats a floor as a declaration rather than a checked value. A fourth way to compare the wrong thing is to read the comment instead of the line.
The two blind spots the issue names are not closed by this, and I am not claiming they are.
ansible_requirements_parity_test.pystill compares against the union, and--strictstill cannot fail on a stale floor declaration. A future divergence between these three files would be just as invisible. That is a guard gap rather than this issue's subject — this one asked for the pin to be bumped, and the pin is bumped. If the guard gap is wanted as work, it deserves its own issue rather than holding this one open, since nothing here would tell a reader that is what remains.No criteria were ticked: the issue carries no checklist, and its single stated fix is verified above.