Pin graphql-core below 3.3 (main linter red)

[JSv4]

Problem

Backend CI on main is red (linter/mypy), and so is every PR rebased on it:

config/graphql/automation.py:151: error: "CollectedFields" has no attribute "values"
opencontractserver/tests/test_coverage_core_scalars.py:45: error: Argument "values" to "ListValueNode" has incompatible type ...

graphql-core is not pinned. It arrives only through strawberry-graphql==0.327.7, which declares graphql-core>=3.2.0,<3.4.0. graphql-core 3.3.0 has now been released, so fresh installs resolve to it. The last green main run (Sep 24) installed 3.2.12.

This is a runtime break as well as a typing error. In 3.3, graphql.execution.collect_fields(schema, fragments, variable_values, runtime_type, operation) takes FragmentDetails and an OperationDefinitionNode and returns a CollectedFields NamedTuple. automation.py::_check passes a selection set and calls .values() on the result, so the scoped-automation selection check would raise under 3.3.

Fix

Pin graphql-core>=3.2,<3.3 in requirements/base.txt. Moving to 3.3 means porting _check deliberately and is left as a follow-up.

Unblocks dependabot PRs #2417, #2410, #2407.

[claude]

Review: LGTM.

• Fix is minimal and correct. Pinning graphql-core>=3.2,<3.3 next to the strawberry pin is the right place. It restores the 3.2.12 resolution that the last green main run used, and the inline comment explains why.
• Changelog fragment follows the changelog.d/ convention, with file and line references and the rationale.
• No tests needed. This is a dependency pin, and the existing automation and scalar tests cover the behaviour once CI resolves 3.2.x.

Suggestions, none blocking:

1. Open a tracking issue for porting automation.py::_check to the 3.3 collect_fields signature, and reference it in the comment or fragment. Otherwise the pin may stay forever.
2. Check that no other requirements file (local.txt, production.txt) or a lockfile pins graphql-core differently. Also confirm the Docker images rebuild from base.txt.
3. Dependabot may try to bump graphql-core. Consider adding an ignore rule for >=3.3 in .github/dependabot.yml if it is tracked there.

[claude]

Review: LGTM. Small, well-scoped fix.

• Pinning graphql-core>=3.2,<3.3 in requirements/base.txt addresses the root cause (transitive dep drifting to 3.3). It sits next to the strawberry pin with a clear comment.
• Mirroring the pin in the mypy hook's additional_dependencies is necessary, since that env resolves independently. Syncing strawberry-graphql to 0.327.7 removes a drift source.
• The changelog fragment follows the changelog.d/ convention.

Non-blocking notes:

1. The hook pin and base.txt are duplicated by hand and can drift again. A comment is there, which is fine for now. Remove both pins together when the follow-up port of automation.py::_check to 3.3 lands.
2. A lockfile or constraints file would stop the next unpinned transitive dependency from breaking main the same way, if you want that later.
3. No tests are needed for a pin. CI going green on the linter is the check.

Please do open the follow-up issue for the 3.3 port so the upper bound doesn't linger.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!