Why CI is red

The ty static check client/server package jobs have been failing on main and on every PR branched from it since #1477 landed (2d28c1c, Aug 14). It is not PR-specific and it is not a CI auto-upgrade -- the workflow already runs uv run --frozen, so it faithfully installs whatever uv.lock says.

#1477 refreshed the whole uv.lock alongside its feature work: 139 packages changed version, 24 were added. Two of those bumps broke the type checker:

1. ty 0.0.38 -> 0.0.59

pyproject.toml says ty~=0.0.38, which expands to >=0.0.38, ==0.0.*. For a pre-1.0 checker that adds diagnostics on essentially every release, that is not a pin -- anything below 0.1.0 is fair game. So a routine relock jumped the checker 21 releases forward.

0.0.59 reports 1 new error in the client package and 7 more in the server package (not-subscriptable, missing-argument on pydantic models, etc.) that 0.0.38 did not.

2. nebula5-python 5.2.2 -> 5.3.0

5.3.0 restructured nebulagraph_python.client, deleting client.py, _session.py and _session_pool.py. NebulaAsyncClient, SessionConfig and SessionPoolConfig no longer exist (they are now AsyncNebulaClient, ConnectionConfig and NebulaPoolConfig, with session pooling replaced by connection pooling). That produces the remaining 10 unresolved-import errors.

This one is worth calling out separately: it is a real runtime break of the nebula backend, not just a typing complaint. ty is the only reason we noticed. 5.3.0 also adds pool==0.1.2.dev0 and HuggingFace datasets as hard runtime dependencies.

Evidence

Checked out at 2d28c1c1 and its parent, uv sync --frozen --all-extras, then ran the exact CI commands:

The third row is what separates the two causes: 7 of the 17 server errors are the new ty, the other 10 are the new nebula5-python.

The fix

• ty~=0.0.38 -> ty==0.0.38, matching the existing ruff==0.15.14 convention in the same dependency group. Checker upgrades then arrive as their own reviewable Dependabot PR (as ty 0.0.32 -> 0.0.35 and 0.0.24 -> 0.0.32 did), where the accompanying code fixes can land with the bump, instead of riding along invisibly in an unrelated lockfile refresh.
• nebula5-python>=5.2.1 -> nebula5-python>=5.2.1,<5.3, restoring the version the code is actually written against.
• Relocked. The diff touches only those two packages, plus dropping pool, datasets, dill and multiprocess, which only entered the lock as transitive deps of nebula 5.3.0. The spaCy/multihop additions from [Feat] add RaragQueryAgent, an optimized ChainOfQueryAgent for multi-hop retrieval #1477 are untouched.

Verification

All six lint.yml ty matrix cells pass locally on this branch:

common   py3.10  : All checks passed!
common   py3.14  : All checks passed!
client   py3.10  : All checks passed!
client   py3.14  : All checks passed!
server   py3.12  : All checks passed!
server   py3.14  : All checks passed!

ruff check, ruff format --check and uv lock --check also pass.

Follow-ups, deliberately not in this PR

1. Adopt ty 0.0.59 and fix the 8 diagnostics it surfaces. Better as its own PR so the code changes are reviewed against the checker change.
2. Port the nebula backend to 5.3.0's client API. Needs someone who can exercise a real NebulaGraph instance; the rename is not mechanical (session pool -> connection pool).
3. Consider guarding wholesale relocks. check-uvlockfile.yml verifies that uv.lock is consistent with pyproject.toml, but nothing flags a PR that silently moves 139 unrelated packages. Exact-pinning the two linters that gate CI closes the sharpest edge of this; a broader policy is a separate discussion.

🤖 Generated with Claude Code