Repository navigation
tech-debt(deps): the protobuf constraint and its inline rationale contradict each other in both requirements files #15070
Description
requirements.txt and autobot-backend/requirements.txt both carry a protobuf constraint whose inline rationale contradicts the constraint itself:
protobuf>=7.36.0,<8.0.0 # capped <7.0: opentelemetry-proto (otel 1.42) requires protobuf<7.0;
# Dependabot's 7.35.1 is unsatisfiable. 6.33.6 = latest installable (#4061)
The comment asserts three things that the line it annotates denies: that the cap is <7.0 (it is <8.0.0), that a 7.x floor is unsatisfiable (the floor is 7.36.0), and that 6.33.6 is the latest installable version.
This is not a new regression — the cap was evidently raised from <7.0 to <8.0.0 at some point without updating the note, and Dependabot has since walked the floor up twice (7.35.1 → 7.36.0 in #14951) underneath a comment that says such a floor cannot install.
Why it matters more than a stale comment usually would: this note exists specifically to stop someone "fixing" the constraint back down. A future reader reconciling the two has to guess which half is current, and the comment is the more emphatic of the two — so the likely outcome is a well-intentioned revert to <7.0, breaking whatever needed the newer protobuf.
Acceptance criteria
- Establish which is true today: does
opentelemetry-proto(at the version this repo resolves) still requireprotobuf<7.0? Record the resolved version and the actual requirement, not the recollection in the comment. - Make the constraint and its comment agree, in both files. If the cap is legitimately
<8.0.0, rewrite the note to say why it was raised and what the real incompatibility boundary is now. If<7.0is still correct, the constraint is wrong and the floor must come down — in which case say how CI has been passing. - Check whether the same stale-rationale pattern appears on other pinned lines in these two files; the
# cappednote is duplicated verbatim across both, so any correction has to land in both places or it re-forks.
Found while reviewing #14951 (Dependabot all-dependencies group bump). Refs #4061.
Activity
fix(deps): correct the protobuf rationale and guard the two files aga…
github-actions commentedon Aug 28, 2026
PR #15115 (merged to
Dev_new_gui) references this issue with a close keyword.If this issue is fully resolved, close it manually. If work remains, no action is needed.
mrveiss commentedon Aug 28, 2026
Closing — verified against the merged base, not the PR diff
Delivered by #15115, merged as
25338e81aonDev_new_gui. Every reference below is read fromorigin/Dev_new_gui.requirements.txt:11-14now records it in the file itself: the pinnedopentelemetry-proto==1.44.0(requirements.txt:56) declaresprotobuf<8.0,>=5.0, and transitivegoogleapis-common-protos 1.75.1declaresprotobuf<8.0.0,>=6.33.5. Answer: no, nothing requires<7.0any more —<8.0is the real boundaryrequirements.txt:32=protobuf>=7.36.0,<8.0.0under a rationale block (:9-31) that now argues for<8.0.0and records why the old note said<7.0;autobot-backend/requirements.txt:43no longer duplicates the note — it carries the identical specifier and points at the root blockfastapi,websockets,opencv-python-headless,langchain,langchain-core,langgraph— every one citing a different package's requirement rather than contradicting its own; onlyprotobufwas self-denying. The re-fork half is now mechanical, not editorial:tools/lint/check_requirements_pin_parity.pyfails on any package declared in both files with differing specifiers, wired as a required step at.github/workflows/code-quality.yml:566, registered intools/lint/check_code_quality_guard_reach.py:59so its own inputs are proven covered by thebackendpaths-filter, and unit-covered byrepo_tests/requirements_pin_parity_test.pyThe guard also fails on an empty comparison (a renamed/emptied file, or the last shared package deduplicated) rather than passing vacuously — the #15087 shape. Four packages are currently doubly declared:
protobuf,aiosqlite,defusedxml,python-docx;autobot-backend/requirements.txt-r-includes the root file, and pip resolves the intersection.What is not proven here
opentelemetry-protoMETADATA read is PR fix(deps): correct the protobuf rationale and guard the two requirements files against divergence (#15070) #15115's forensic evidence, taken as recorded — the repo-side half of it (that the pin is1.44.0) I did verify atrequirements.txt:56.deps(protobuf): move the tripwire literal and the floor rationale wit…
chore(deps): bump the all-dependencies group in /autobot-backend with…
fix(deps): mirror the bumped floors into ansible and the shipped mani…
fix(deps): a floor report states its role and scope; detect a product…