You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Two upstream ci.yml changes, filed together because they touch the same file and want the same conversation with the same maintainer. Either can go up alone; neither should ride along on an unrelated PR.
1. The protoc action is unpinned, and it fails runs
Observed 2026-07-25 on tikv/client-rust PR 555: the unit test job died after 6 seconds with
##[error]Error: unable to get latest version
from arduino/setup-protoc@v1. Nothing was compiled and no test ran. The other three jobs on that same run passed, and the identical code passed on a retrigger with only the committer date changed — so it is the action, not the code.
ci.yml calls it three times (once per job) with a floating version: '3.x', so every job resolves the protobuf release list over the GitHub API on every run. That is three dice rolls per run, across every PR, each capable of red-X-ing a job before the build starts. A repo-token is already passed, so the usual rate-limit advice does not apply — the resolution step itself is the fragile part.
The action is also stale enough that GitHub is force-migrating its runtime: every run logs
Node.js 20 is deprecated. The following actions target Node.js 20 but are being forced to run on Node.js 24: actions/checkout@v4, arduino/setup-protoc@v1
Scope:
Pin protoc to a concrete version rather than 3.x, and/or move to a maintained major (arduino/setup-protoc@v3) which resolves differently.
Whatever the fix, it must remove the per-job API resolution — that is the actual failure mode, not the version number.
Small, self-contained, and unlike item 2 it is not blocked on anything: it is a straight CI-reliability fix that costs the maintainers nothing to accept.
This is a different failure from #44. #44 is about test flakes — txn_cleanup_* hanging until nextest terminates the job. This one never reaches the tests. Both produce a red X on an in-flight PR, which is why they are easy to confuse; they need different fixes.
2. TIKV_VERSION is v8.5.5, which predates features the repo now vendors
§0 records the cluster floor as a fact about upstream: client-rust's ci.yml sets TIKV_VERSION: v8.5.5, and §0 already flags "the version-support policy itself is a gap to file upstream (§9)". Splitting tikv/client-rust PR 550 turned that from a policy observation into a concrete cost.
v8.5.5 (2026-01-15) predates shared locks; v8.5.6 (2026-04-14) is the first release that emits them, v8.5.7 (2026-07-09) is current. So upstream CI now runs a server roughly six months behind the kvproto revision tikv/client-rust PR 550 vendors (b41e863, 2026-06-22) — the same revision client-go pins. Upstream CI therefore cannot exercise several of the semantics its own vendored protos describe, tikv/client-rust PR 556's refusal path among them, which is why that PR ships unit-tested and says so in its body.
For contrast, client-go's integration.yml runs pingcap/tikv:nightly.
Scope:
Open an upstream PR bumping TIKV_VERSION in .github/workflows/ci.yml, most likely to v8.5.7 — same release family, so the blast radius is a patch bump rather than a major-version move.
Frame it as a question as much as a patch: what is the intended support floor, and should CI track the kvproto revision the repo vendors? The answer belongs upstream, not here.
Deliberately not bundled into tikv/client-rust PR 550, tikv/client-rust PR 555 or tikv/client-rust PR 556. pingyu asked for that PR to be narrowed to the re-vendor, and arriving with an unrequested CI change attached would undercut the split. Note the pin was last set by pingyu in tikv/client-rust PR 518, so they are also the right person to ask.
Blocked on tikv/client-rust PR 550 merging — proposing a CI change while the PR it came from is unmerged just adds review surface. Item 1 is not blocked and can go up first.
Two upstream
ci.ymlchanges, filed together because they touch the same file and want the same conversation with the same maintainer. Either can go up alone; neither should ride along on an unrelated PR.1. The protoc action is unpinned, and it fails runs
Observed 2026-07-25 on tikv/client-rust PR 555: the
unit testjob died after 6 seconds withfrom
arduino/setup-protoc@v1. Nothing was compiled and no test ran. The other three jobs on that same run passed, and the identical code passed on a retrigger with only the committer date changed — so it is the action, not the code.ci.ymlcalls it three times (once per job) with a floatingversion: '3.x', so every job resolves the protobuf release list over the GitHub API on every run. That is three dice rolls per run, across every PR, each capable of red-X-ing a job before the build starts. Arepo-tokenis already passed, so the usual rate-limit advice does not apply — the resolution step itself is the fragile part.The action is also stale enough that GitHub is force-migrating its runtime: every run logs
Scope:
3.x, and/or move to a maintained major (arduino/setup-protoc@v3) which resolves differently.This is a different failure from #44. #44 is about test flakes —
txn_cleanup_*hanging until nextest terminates the job. This one never reaches the tests. Both produce a red X on an in-flight PR, which is why they are easy to confuse; they need different fixes.2.
TIKV_VERSIONis v8.5.5, which predates features the repo now vendors§0 records the cluster floor as a fact about upstream: client-rust's
ci.ymlsetsTIKV_VERSION: v8.5.5, and §0 already flags "the version-support policy itself is a gap to file upstream (§9)". Splitting tikv/client-rust PR 550 turned that from a policy observation into a concrete cost.v8.5.5 (2026-01-15) predates shared locks;
v8.5.6(2026-04-14) is the first release that emits them,v8.5.7(2026-07-09) is current. So upstream CI now runs a server roughly six months behind the kvproto revision tikv/client-rust PR 550 vendors (b41e863, 2026-06-22) — the same revision client-go pins. Upstream CI therefore cannot exercise several of the semantics its own vendored protos describe, tikv/client-rust PR 556's refusal path among them, which is why that PR ships unit-tested and says so in its body.For contrast, client-go's
integration.ymlrunspingcap/tikv:nightly.Scope:
TIKV_VERSIONin.github/workflows/ci.yml, most likely to v8.5.7 — same release family, so the blast radius is a patch bump rather than a major-version move.Deliberately not bundled into tikv/client-rust PR 550, tikv/client-rust PR 555 or tikv/client-rust PR 556. pingyu asked for that PR to be narrowed to the re-vendor, and arriving with an unrequested CI change attached would undercut the split. Note the pin was last set by pingyu in tikv/client-rust PR 518, so they are also the right person to ask.
Blocked on tikv/client-rust PR 550 merging — proposing a CI change while the PR it came from is unmerged just adds review surface. Item 1 is not blocked and can go up first.
Roadmap §9 (upstream engagement) / §0 (cluster floor) / Phase 0.