chore(rust): clear all build warnings + retry flaky Windows linker#1408
chore(rust): clear all build warnings + retry flaky Windows linker#1408sansyrox wants to merge 2 commits into
Conversation
Silence all 71 Rust build warnings and harden the flaky Windows CI build. Warnings (71 -> 0): - Migrate pyo3 0.27 deprecations: Python::with_gil -> Python::attach, downcast/downcast_bound/downcast_exact -> cast/cast_bound/cast_exact, and TaskLocals::clone_ref -> clone (only the 6 TaskLocals call sites; the ~29 Py::clone_ref calls are the correct, non-deprecated API and are untouched). - Allow dead code at module level in the adapted-from-Granian runtime scaffolding (runtime.rs, callbacks.rs, asyncio.rs, conversion.rs) whose helpers aren't all wired up yet. - Rename .cargo/config -> .cargo/config.toml (the bare name is deprecated). Flaky Windows build: - The hosted Windows toolchain intermittently fails to link with `LNK1181: cannot open input file 'pythonXY.lib'`. Retry the nox step up to 3x on Windows only, so a one-off linker hiccup doesn't fail the whole run (Linux/macOS are unchanged, so their failures are never masked). - Bump actions/checkout@v4 -> v5 to drop the Node 20 deprecation warning. Pure API migration: full unit (102) and integration (353) suites pass; no behavior change. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughThe PR migrates the PyO3 GIL-acquisition API from ChangesPyO3 API Migration
CI Workflow Reliability Improvements
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/python-CI.yml:
- Around line 65-75: The retry loop in the nox command block retries every
failure indiscriminately, which can mask real issues when they pass on
subsequent runs. Modify the retry logic to capture the nox command output and
only retry when the specific LNK1181 linker error (related to python*.lib) is
detected in the output. For all other failure types, the loop should exit
immediately with a failure status rather than attempting retries. This ensures
that only the known transient linker issue gets retried while actual test, lint,
or build failures fail fast.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 6b659ab2-f0ba-4edd-b1e5-77d18f9b17b2
📒 Files selected for processing (17)
.cargo/config.toml.github/workflows/python-CI.ymlsrc/asyncio.rssrc/callbacks.rssrc/conversion.rssrc/executors/mod.rssrc/executors/web_socket_executors.rssrc/routers/http_router.rssrc/routers/middleware_router.rssrc/runtime.rssrc/server.rssrc/types/function_info.rssrc/types/headers.rssrc/types/mod.rssrc/types/request.rssrc/types/response.rssrc/websockets/mod.rs
| for attempt in 1 2 3; do | ||
| echo "::group::nox attempt $attempt" | ||
| if nox --non-interactive --error-on-missing-interpreter -p ${{ matrix.python-version }}; then | ||
| echo "::endgroup::" | ||
| exit 0 | ||
| fi | ||
| echo "::endgroup::" | ||
| echo "nox attempt $attempt failed; retrying..." | ||
| done | ||
| echo "nox failed after 3 attempts" | ||
| exit 1 |
There was a problem hiding this comment.
Retry loop should only retry the known transient linker failure.
The current Windows loop retries every nox failure. That can hide unrelated intermittent regressions (tests/lint/build) when a second run passes. Scope retries to the specific LNK1181 ... python*.lib signature and fail immediately for all other failures.
Suggested patch
- name: Test with Nox (Windows, retry transient linker failures)
if: runner.os == 'Windows'
shell: bash
run: |
for attempt in 1 2 3; do
echo "::group::nox attempt $attempt"
- if nox --non-interactive --error-on-missing-interpreter -p ${{ matrix.python-version }}; then
+ nox --non-interactive --error-on-missing-interpreter -p ${{ matrix.python-version }} 2>&1 | tee nox.log
+ status=${PIPESTATUS[0]}
+ if [ "$status" -eq 0 ]; then
echo "::endgroup::"
exit 0
fi
+ if ! grep -Eq "LNK1181: cannot open input file 'python[0-9]+\.lib'" nox.log; then
+ echo "::endgroup::"
+ echo "nox failed for a non-transient reason; not retrying."
+ exit "$status"
+ fi
echo "::endgroup::"
echo "nox attempt $attempt failed; retrying..."
done
echo "nox failed after 3 attempts"
exit 1📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| for attempt in 1 2 3; do | |
| echo "::group::nox attempt $attempt" | |
| if nox --non-interactive --error-on-missing-interpreter -p ${{ matrix.python-version }}; then | |
| echo "::endgroup::" | |
| exit 0 | |
| fi | |
| echo "::endgroup::" | |
| echo "nox attempt $attempt failed; retrying..." | |
| done | |
| echo "nox failed after 3 attempts" | |
| exit 1 | |
| for attempt in 1 2 3; do | |
| echo "::group::nox attempt $attempt" | |
| nox --non-interactive --error-on-missing-interpreter -p ${{ matrix.python-version }} 2>&1 | tee nox.log | |
| status=${PIPESTATUS[0]} | |
| if [ "$status" -eq 0 ]; then | |
| echo "::endgroup::" | |
| exit 0 | |
| fi | |
| if ! grep -Eq "LNK1181: cannot open input file 'python[0-9]+\.lib'" nox.log; then | |
| echo "::endgroup::" | |
| echo "nox failed for a non-transient reason; not retrying." | |
| exit "$status" | |
| fi | |
| echo "::endgroup::" | |
| echo "nox attempt $attempt failed; retrying..." | |
| done | |
| echo "nox failed after 3 attempts" | |
| exit 1 |
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 67-67: code injection via template expansion (template-injection): may expand into attacker-controllable code
(template-injection)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/python-CI.yml around lines 65 - 75, The retry loop in the
nox command block retries every failure indiscriminately, which can mask real
issues when they pass on subsequent runs. Modify the retry logic to capture the
nox command output and only retry when the specific LNK1181 linker error
(related to python*.lib) is detected in the output. For all other failure types,
the loop should exit immediately with a failure status rather than attempting
retries. This ensures that only the known transient linker issue gets retried
while actual test, lint, or build failures fail fast.
The Preview Release / Release wheel-build workflows intermittently failed all Windows jobs at once: the Microsoft Store python alias stub (WindowsApps\python3.exe) raises EACCES when a Node-based action probes PATH, and without fail-fast: false that one flake cancelled the other 9 matrix jobs. - Add fail-fast: false to every matrix so a single runner flake no longer cascades to cancel the rest. - Remove the Windows Store python alias stubs before setup-python in the Windows jobs, which addresses the EACCES probe failure. - Bump release-CI checkout v3 -> v4. Infra-only change; validates on CI (Windows builds don't run on PRs from the main test workflow). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/preview-deployments.yml:
- Line 57: All four invocations of actions/checkout in this workflow are using
mutable version tags (`@v4`) instead of pinned commit SHAs, which is less secure
for supply-chain hardening. Additionally, credential persistence is enabled by
default. For each of the four actions/checkout steps (lines 25, 57, 92, and
125), replace the `@v4` tag with a pinned full commit SHA (keeping a version
comment for readability) and add persist-credentials: false configuration option
to prevent Git credentials from being leaked if the workflow is compromised.
In @.github/workflows/release-CI.yml:
- Line 61: The actions/checkout@v4 step needs to be hardened for security by
pinning it to a specific commit SHA instead of using the version tag, and by
adding the persist-credentials configuration set to false. Locate the uses
statement with actions/checkout@v4, replace the version tag with a specific
commit SHA (e.g., `@abc123def`...), and add a with section that includes
persist-credentials: false to prevent token exposure and mitigate
tag-retargeting attacks.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 3e040267-6961-495d-92e2-3d791330c685
📒 Files selected for processing (2)
.github/workflows/preview-deployments.yml.github/workflows/release-CI.yml
| python-version: ["3.10", "3.11", "3.12", "3.13", "3.14"] | ||
| target: [x64, x86] | ||
| steps: | ||
| - uses: actions/checkout@v4 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/preview-deployments.ymlRepository: sparckles/Robyn
Length of output: 6341
🏁 Script executed:
find .github/workflows -type f -name "*.yml" -o -name "*.yaml" | head -20Repository: sparckles/Robyn
Length of output: 257
🏁 Script executed:
rg "actions/checkout" .github/workflows/ -A 3Repository: sparckles/Robyn
Length of output: 4313
🌐 Web query:
GitHub Actions security best practices 2024 2025 actions/checkout pinning
💡 Result:
Securing GitHub Actions workflows, especially when using actions/checkout and other third-party dependencies, relies on several established best practices as of 2026 [1][2][3]. The most critical security measure is ensuring that all actions are referenced by their full-length commit SHA [1][2][4]. Action Pinning Using mutable version tags (e.g., @v4) is insecure because a compromised upstream repository can update the tag to point to a malicious commit [1][5][2]. You must pin actions to a full 40-character commit SHA [2][6][4]. To maintain readability and updateability, it is standard practice to include the version number in a trailing comment [2][6]: - uses: actions/checkout@11bd719 # v4.2.2 Automate this process using tools like Dependabot or Renovate, which can automatically open pull requests to update these SHAs [5][2][6]. Core Security Best Practices 1. Least Privilege Permissions: Never rely on default permissions [2]. Use the permissions key at the workflow or job level to explicitly define only the scopes required [2]. Start with permissions: {} and add necessary scopes incrementally [2]. 2. OIDC for Cloud Authentication: Avoid long-lived secrets (e.g., AWS_ACCESS_KEY_ID) [2]. Use OpenID Connect (OIDC) to federate identity with your cloud provider, allowing the runner to request short-lived, job-specific access tokens [2][7][3]. 3. Protect Secrets: Ensure secrets are scoped to specific environments and use environment protection rules to require manual approval for high-risk deployments [2][3]. 4. Audit Third-Party Actions: Vet third-party actions before inclusion, favoring those from verified creators or those with significant community maintenance [8][9]. If an action is simple, consider implementing the required logic directly in your workflow using native shell commands [3]. 5. Governance Policies: Use repository or organization-level policies to restrict which actions can be used [10][4][3]. This allows you to block all third-party actions by default, requiring explicit approval for those you trust [8][3]. 6. Avoid Risky Triggers: Be cautious with the pull_request_target trigger, especially when combined with actions that check out untrusted code from forks [1][2]. For such workflows, ensure the checkout step runs in a separate, isolated job that does not have access to sensitive secrets [1][3]. For ongoing monitoring, use static analysis tools to scan workflow files for misconfigurations, such as unpinned actions or overly broad permissions [1][2][3].
Citations:
- 1: https://www.datadoghq.com/blog/github-actions-iac-security/
- 2: https://secure-pipelines.com/ci-cd-security/github-actions-security-cheat-sheet/
- 3: https://www.truesec.com/hub/blog/tips-for-supply-chain-security-in-ci-cd-mitigating-risks-from-third-party-github-actions
- 4: https://docs.github.com/en/actions/reference/security/secure-use
- 5: https://emmer.dev/blog/pin-your-github-actions-to-protect-against-mutability/
- 6: https://adaptive-enforcement-lab.com/secure/github-actions-security/action-pinning/sha-pinning/
- 7: https://github.com/github/docs/blob/main/content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-cloud-providers.md
- 8: https://www.stepsecurity.io/blog/third-party-github-actions-governance-best-practices
- 9: https://engineering.salesforce.com/github-actions-security-best-practices-b8f9df5c75f5/
- 10: https://github.com/github/docs/blob/main/content/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise.md
🌐 Web query:
actions/checkout persist-credentials false security hardening
💡 Result:
Setting persist-credentials: false on actions/checkout is a recommended GitHub Actions security hardening step, because it prevents Git credentials (from the checkout step) from being persisted in the workflow’s runner git configuration, reducing exposure if the workflow (or later steps/actions) is compromised [1]. What persist-credentials changes - By default, actions/checkout can persist an auth token/credentials in the local git configuration so later steps can run authenticated git commands; persist-credentials: false opts out of that persistence [2]. How to apply it (example) - Use it on checkout steps that are only reading source code (most CI jobs). For example: - uses: actions/checkout@ with: persist-credentials: false Additional hardening considerations (high impact) 1) Least-privilege for GITHUB_TOKEN - Even with persist-credentials: false, hardening should include restricting the workflow/job permissions for GITHUB_TOKEN (e.g., contents: read for read-only jobs) to minimize blast radius [2][3]. 2) Avoid risky triggers/checkout patterns - Ensure you don’t check out and execute untrusted fork code in privileged contexts (e.g., pull_request_target), which is a common high-risk scenario unrelated to persist-credentials but often co-occurs in insecure workflows [1][4]. Net effect - persist-credentials: false reduces the chance that later workflow steps can reuse stored git credentials left behind by the checkout action, so it’s a sensible default for read-only workflows [1][2].
Citations:
- 1: https://cheatsheetseries.owasp.org/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.html
- 2: https://github.com/actions/checkout/
- 3: https://secure-pipelines.com/ci-cd-security/github-actions-security-cheat-sheet/
- 4: https://www.wiz.io/blog/github-actions-security-guide
Harden all actions/checkout invocations by pinning to commit SHA and disabling credential persistence.
All four checkout steps in this workflow (lines 25, 57, 92, 125) are using mutable version tags (@v4), which is less secure than pinning to a full commit SHA. Additionally, credential persistence is enabled by default. For CI supply-chain hardening, pin each to a commit SHA (with a version comment for readability) and set persist-credentials: false to prevent leakage of Git credentials if the workflow is compromised.
Example patch
- - uses: actions/checkout@v4
+ - uses: actions/checkout@<full_commit_sha_for_v4> # v4.2.2
+ with:
+ persist-credentials: false🧰 Tools
🪛 zizmor (1.25.2)
[warning] 57-60: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 57-57: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/preview-deployments.yml at line 57, All four invocations
of actions/checkout in this workflow are using mutable version tags (`@v4`)
instead of pinned commit SHAs, which is less secure for supply-chain hardening.
Additionally, credential persistence is enabled by default. For each of the four
actions/checkout steps (lines 25, 57, 92, and 125), replace the `@v4` tag with a
pinned full commit SHA (keeping a version comment for readability) and add
persist-credentials: false configuration option to prevent Git credentials from
being leaked if the workflow is compromised.
Source: Linters/SAST tools
| target: [x64, x86] | ||
| steps: | ||
| - uses: actions/checkout@v3 | ||
| - uses: actions/checkout@v4 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, find the release-CI.yml file
find . -name "release-CI.yml" -o -name "release-ci.yml" | head -20Repository: sparckles/Robyn
Length of output: 94
🏁 Script executed:
# List all workflow files to understand the structure
find .github/workflows -type f -name "*.yml" -o -name "*.yaml" 2>/dev/null | head -20Repository: sparckles/Robyn
Length of output: 257
🏁 Script executed:
# Examine the release-CI.yml file around line 61
if [ -f ".github/workflows/release-CI.yml" ]; then
cat -n .github/workflows/release-CI.yml | sed -n '50,70p'
elif [ -f ".github/workflows/release-ci.yml" ]; then
cat -n .github/workflows/release-ci.yml | sed -n '50,70p'
else
echo "File not found, searching..."
find .github -name "*release*" -name "*.yml"
fiRepository: sparckles/Robyn
Length of output: 1140
🏁 Script executed:
# Search for all checkout actions in workflow files to see if hardening exists elsewhere
rg "actions/checkout" .github/workflows --no-heading -B2 -A2Repository: sparckles/Robyn
Length of output: 5022
🏁 Script executed:
# Check the full release-CI.yml to see all checkout actions and any hardening applied
cat -n .github/workflows/release-CI.yml | grep -A5 -B5 "actions/checkout"Repository: sparckles/Robyn
Length of output: 1899
🏁 Script executed:
# Search for any persist-credentials settings across all workflows
rg "persist-credentials" .github/workflows/Repository: sparckles/Robyn
Length of output: 41
🏁 Script executed:
# Check if any checkout actions are pinned to commit SHAs
rg "actions/checkout@[a-f0-9]" .github/workflows/Repository: sparckles/Robyn
Length of output: 41
🏁 Script executed:
# Get the exact lines for all checkout usages in release-CI.yml
cat .github/workflows/release-CI.yml | grep -n "actions/checkout"Repository: sparckles/Robyn
Length of output: 209
🏁 Script executed:
# Check if any checkout action in any workflow has persist-credentials or is pinned
for file in .github/workflows/*.yml; do
echo "=== $file ==="
cat "$file" | grep -A10 "actions/checkout"
doneRepository: sparckles/Robyn
Length of output: 5688
🏁 Script executed:
# Check the entire release-CI.yml to see if any checkout has special configuration
cat .github/workflows/release-CI.ymlRepository: sparckles/Robyn
Length of output: 7618
🌐 Web query:
GitHub Actions checkout security best practices commit SHA pinning persist-credentials
💡 Result:
To secure your GitHub Actions workflows using actions/checkout, follow these industry-standard best practices: 1. Use persist-credentials: false: By default, actions/checkout persists the GITHUB_TOKEN or other credentials in the local git configuration [1][2]. This makes the token available to any subsequent step or third-party action in your job, increasing the risk of accidental exposure or misuse [3][2]. You should explicitly set this to false unless your workflow specifically requires authenticated git operations (e.g., pushing commits back to the repository) [4][3]. - uses: actions/checkout@v4 with: persist-credentials: false 2. Pin Actions to a Full Commit SHA: Using mutable tags like @v4 or @v4.1.1 is insecure because an attacker who compromises the action repository could move the tag to a malicious commit [5][6]. Always pin third-party actions, including actions/checkout, to their full 40-character commit SHA [5][6]. You can retain readability by adding the version tag as a comment [5]. - uses: actions/checkout@b4ffde6 # v4.1.1 3. Additional Security Considerations: - Principle of Least Privilege: Always define the permissions block at the job or workflow level, granting only the minimum required access (e.g., permissions: contents: read) rather than relying on default permissions [5]. - Avoid Risky Triggers: Be cautious with events like pull_request_target, which can execute fork code in a trusted context [4][5]. Always review the security implications before using them [1]. - Automation: Consider using automated security tools (e.g., Dependabot, Zizmor) to enforce these practices, such as automatically updating SHA pins and identifying insecure configurations [4][5].
Citations:
- 1: https://github.com/actions/checkout/
- 2: https://actsense.dev/vulnerabilities/unsafe_checkout/
- 3: https://masteringlaravel.io/daily/2026-06-18-the-security-default-we-change-in-githubs-checkout-action
- 4: https://cheatsheetseries.owasp.org/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.html
- 5: https://secure-pipelines.com/ci-cd-security/github-actions-security-cheat-sheet/
- 6: https://www.stepsecurity.io/blog/pinning-github-actions-for-enhanced-security-a-complete-guide
Pin checkout action to commit SHA and disable credential persistence.
The actions/checkout@v4 step should be commit-SHA pinned and configured with persist-credentials: false to reduce token exposure and prevent tag-retargeting attacks.
Suggested patch
- - uses: actions/checkout@v4
+ - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+ with:
+ persist-credentials: false📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - uses: actions/checkout@v4 | |
| - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1 | |
| with: | |
| persist-credentials: false |
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 61-64: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 61-61: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/release-CI.yml at line 61, The actions/checkout@v4 step
needs to be hardened for security by pinning it to a specific commit SHA instead
of using the version tag, and by adding the persist-credentials configuration
set to false. Locate the uses statement with actions/checkout@v4, replace the
version tag with a specific commit SHA (e.g., `@abc123def`...), and add a with
section that includes persist-credentials: false to prevent token exposure and
mitigate tag-retargeting attacks.
Source: Linters/SAST tools
1 participant
Summary
Silences all 71 Rust build warnings and hardens the flaky Windows CI build (the intermittent
windows tests with python Xfailures onmain).Warnings: 71 → 0
Python::with_gil→Python::attach(30)downcast/downcast_bound/downcast_exact→cast/cast_bound/cast_exact(~20)TaskLocals::clone_ref→clone— only the 6TaskLocalscall sites; the ~29Py::clone_refcalls are the correct, non-deprecated API and are deliberately left untouched.#![allow(dead_code)]on the adapted-from-Granian runtime scaffolding (runtime.rs,callbacks.rs,asyncio.rs,conversion.rs), whose helpers aren't all wired up yet (matching the existing#[allow(dead_code)]usage there)..cargo/config→.cargo/config.toml(the bare filename is deprecated by cargo).Flaky Windows build
The hosted Windows toolchain intermittently fails to link with:
On Windows, pyo3 extension modules must link
pythonXY.lib, and the hosted Python'slibsdir is occasionally unreadable mid-build — a transient that turns CI red at random. This:noxstep up to 3× on Windows only, so a one-off linker hiccup doesn't fail the run. Linux/macOS are unchanged, so genuine failures there are never masked.actions/checkout@v4→@v5to drop the Node 20 deprecation notice.Test plan
cargo check— 0 warnings (was 71),cargo fmtclean.main(PRs are ubuntu-only), so the retry takes effect on merge rather than on this PR.🤖 Generated with Claude Code
Summary by CodeRabbit