fix(test): assert protobuf parity, not a version literal, in the reach check (#15981)

[mrveiss]

Closes #15981

Thinking Path

repo_tests/requirements_pin_parity_test.py:138 was failing every protobuf bump
and holding up the dependabot queue — red on #15972 and #15977, and one of the
two failures on #15975 before it was closed.

The test's own docstring states its subject:

The regression this guard exists for must be inside its reach, not merely near it.

That is a reach check, and the line above it already performs it
(assert "protobuf" in set(root) & set(backend)). The failing line additionally
asserted a hard-coded version literal, which is a claim about which version —
something neither this test nor #15070 (whose subject is divergence between two
files) is about.

The failure mode is the one this repo keeps finding: it reported a version
mismatch, so it read as the guard working correctly rather than as a reach
check over-specifying. Three dependabot PRs sat red without the cause being
obvious, and the literal would need hand-editing on every bump — an edit that
restores the test without restoring any property.

What Changed

One assertion, from a version literal to the parity the guard is actually about:

-    assert root["protobuf"] == backend["protobuf"] == ">=7.36.0,<8.0.0"
+    assert root["protobuf"] == backend["protobuf"]

Deliberately not changed: the two literals in the test below it. Those look
identical in shape and are the opposite case. test_the_rationale_matches_the_pin
asserts opentelemetry-proto == "==1.44.0" and the protobuf constraint
together, on purpose: otel's pin determines which protobuf majors are admissible,
the two drifted apart historically (#10589 moved otel, #10678 raised protobuf the
next day, the note was updated neither time), and its failure message tells the
reader to re-read Requires-Dist and update both. That test is meant to fail on
a bump. I nearly "fixed" it before reading its docstring.

So a protobuf bump still requires a human to revisit the otel rationale — which
is correct, and is why this change unblocks the reach check without making
protobuf bumps automatic.

Verification

• repo_tests/requirements_pin_parity_test.py — 13 passed.
• The divergence property AC bug(test): a reach check pins a protobuf version literal, so every bump fails it #15981 asks for is already proven by fixture at
  :45-48 (test_compute_divergence_flags_a_package_pinned_differently_in_each_file):
  differing pins are flagged, identical ones are not. No duplicate added.
• The reach assertion at :137 is untouched, so the property this test exists
  for is unchanged.

Model Used

Claude Opus 5 (1M context)

Summary by CodeRabbit

• Tests
  • Updated dependency consistency checks to verify that protobuf requirements match across supported requirement files.
  • Version-specific protobuf compatibility remains validated separately through the OpenTelemetry compatibility checks.

Single-issue rationale: this is a one-line change to a single assertion, currently blocking the dependabot queue on python-suite shard 8/12 (#15972, #15977, #15978). Batching it with any other issue would delay the unblock behind a larger review, and there is no same-scope issue open — the sibling literals in the same file are a deliberate tripwire that this PR explicitly does not touch.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Advanced

Run ID: f26ed683-4bca-44ea-bf22-25d586fcdb2d

📥 Commits

Reviewing files that changed from the base of the PR and between 8f95130 and 476173e.

📒 Files selected for processing (1)

• repo_tests/requirements_pin_parity_test.py

Included review availability: Your plan provides up to 10 included reviews per hour; 8 remain after this review.

---

📝 Walkthrough

Walkthrough

The protobuf parity test now checks that the root and backend requirements files contain identical protobuf constraints. It no longer enforces a specific version.

Changes

Protobuf parity validation

Layer / File(s)	Summary
Relax protobuf parity assertion repo_tests/requirements_pin_parity_test.py	The test removes the fixed protobuf version check and retains comparison of the constraints declared in both requirements files.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Merge Risk: ⚪ Minimal · up to 47617

The protobuf check now permits synchronized dependency updates while continuing to reject mismatched root and backend constraints. The change is ready to merge.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The change meets the linked issue objectives [#15981]. It checks protobuf reach and parity, removes the specific version assertion, preserves divergent-pin failure behaviour through fixtures, and leav…
Out of Scope Changes check	✅ Passed	The changes are limited to the requirements parity test and support the linked issue objectives [#15981]. No unrelated code changes are identified.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 2 functions across 1 files.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main change: the test now checks protobuf parity instead of a hard-coded version literal.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch issue-15981-pin-parity

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

✅ SSOT Configuration Compliance: Passing

🎉 No new hardcoded values of either class — ssot and other both block.

Known backlog in pipeline-scripts/hardcoded_values_baseline.txt is suppressed and tracked in #14371.