security: raise the published Go SDK consumer floor off EOL (1.24.0 → 1.25.0)

[yakimoto]

One line. sdk-go/go.mod: go 1.24.0 → go 1.25.0.

This is the half of the EOL-Go problem that #26 does not reach

#26 is correct and should still land — it bumps go-version: "1.22" → "1.26" in test-go.yml and release-go.yml. But it is worth knowing what that pin was actually doing, because the CI log says something different from what the workflow file says:

Setup go version spec 1.22
go version go1.22.12 linux/amd64
GOTOOLCHAIN='auto'
go: downloading go1.24.0 (linux/amd64)     <-- this is the compiler that ran

(run 27102642727, main)

setup-go installed 1.22.12, and then the Go toolchain switched itself up to 1.24.0 because sdk-go/go.mod demands it. So the workflow pin was already inert — the go directive selected the compiler, not the pin. Both versions are end-of-life (1.22 on 2025-02-11, 1.24 on 2026-02-10), so the finding held either way, but the mechanism named in it was the wrong one.

That matters for a second reason: github.com/wave-av/sdks/sdk-go is published (live on the module proxy, v0.1.0). Its go directive is the minimum Go it demands of everyone who installs it, and that minimum is currently an EOL release. No workflow change can fix a floor that ships inside go.mod.

Why 1.25.0

Supported Go today is 1.25 and 1.26. 1.25 is the oldest release still receiving security fixes, so it clears EOL while keeping the consumer window as wide as it can be. Deliberate, not incidental.

Checked that nothing downstream needs more — after the bump, the highest go requirement in the whole module graph is this module itself:

golang.org/x/sync              1.24.0
golang.org/x/sys               1.24.0
github.com/wave-av/sdks/sdk-go 1.25.0

Verification

Against go1.26.4, before and after:

go build ./...   ok
go vet ./...     ok
go test ./...    ok   github.com/wave-av/sdks/sdk-go/wave

The heavy go-ethereum v1.17.3 dependency tree resolves and compiles unchanged.

Relationship to #26

Independent files, no conflict — #26 touches .github/workflows/*, this touches sdk-go/go.mod. Land both:

• chore(deps): update dependency go to 1.26 #26 stops CI installing an EOL toolchain, and makes the pin operative again (1.26 ≥ this module's floor, so GOTOOLCHAIN has nothing to switch up to).
• this stops the published SDK advertising an EOL minimum to its consumers.

Found while burning down the Aikido "EOL runtime" critical class fleet-wide. Most of that class measured as false severity — repos pinning go-version: stable build with current Go whatever their directive says. This repo is one of the genuine ones, and it turned out to be genuine for a different reason than the finding claimed.

🤖 Generated with Claude Code

---

Note

Low Risk
Only the go directive and changelog change; no runtime or API code. Risk is limited to consumers who cannot use Go 1.25+.

Overview
Raises the published minimum Go for github.com/wave-av/sdks/sdk-go from 1.24.0 to 1.25.0 in sdk-go/go.mod. No SDK source changes.

1.25 is the oldest release still getting security fixes after 1.24 EOL (2026-02-10). Consumers on an older toolchain or GOTOOLCHAIN=off must upgrade; default GOTOOLCHAIN=auto can fetch a suitable toolchain.

CHANGELOG.md documents this as a breaking change for Go SDK consumers and clarifies that bumping CI go-version alone does not fix a floor that ships in go.mod (CI was already compiling with 1.24 via toolchain auto-switch).

^{Reviewed by Cursor Bugbot for commit 86ded9d. Configure here.}

---

Note

Raise minimum Go version in published SDK go.mod from 1.24.0 to 1.25.0

Introduces a GO_VERSION constant in render_go.py as the single source of truth for the go directive emitted into sdk-go/go.mod, replacing a hardcoded string. The generated go.mod now declares go 1.25.0. Risk: this is a breaking change for Go SDK consumers still on Go 1.24.

^{Macroscope summarized ed32763.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_b93c0dca-6bf3-4da9-b49a-ad0954535015)

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Summary by CodeRabbit

• Documentation

  • Added an Unreleased changelog entry documenting the Go SDK’s minimum version update to Go 1.25.
  • Documented the related toolchain impact and regeneration details.

• Updates

  • Updated the Go SDK module requirement to Go 1.25.0.

Walkthrough

The Go SDK minimum version changed from Go 1.24.0 to Go 1.25.0. The Go generator now controls the emitted module version through GO_VERSION, and the changelog documents the change.

Changes

Go version upgrade

Layer / File(s)	Summary
Generator and module version update codegen/render_go.py, sdk-go/go.mod, CHANGELOG.md	The generator now uses GO_VERSION set to 1.25.0. The generated Go module declares Go 1.25.0. The changelog documents the minimum version increase and regeneration details.

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

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely describes the main change: raising the published Go SDK consumer minimum from Go 1.24.0 to Go 1.25.0.
Description check	✅ Passed	The description directly explains the Go version change, its consumer impact, rationale, verification, and relationship to the related CI workflow change.

✨ 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 fix/eol-go-consumer-floor

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch fix/eol-go-consumer-floor

---

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

[qodo-code-review]

PR Summary by Qodo

Raise Go SDK minimum supported Go version to 1.25.0 (off EOL)

⚙️ Configuration changes 🐞 Bug fix 🕐 Less than 5 minutes

AI Description

• Bump published sdk-go module’s minimum Go version from 1.24.0 to 1.25.0.
• Ensure consumers and CI no longer select an end-of-life Go toolchain via go.mod.
• Keep the widest supported consumer window by targeting the oldest security-supported Go.

Diagram

graph TD
  C["SDK consumer project"] --> M["github.com/wave-av/sdks/sdk-go"] --> GM["sdk-go/go.mod (go 1.25)"] --> GT{{"Go toolchain"}}

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Bump floor directly to Go 1.26

• ➕ Eliminates ambiguity: aligns with newest supported release
• ➕ May reduce future bump frequency
• ➖ Shrinks the supported consumer window unnecessarily compared to 1.25
• ➖ May force upgrades for consumers that could still be secure on 1.25

2. Add a `toolchain` directive (keep `go 1.25.0`)

• ➕ Encourages a specific toolchain in CI/dev while keeping a lower consumer floor
• ➕ Can reduce surprise auto-upgrades if you standardize on one toolchain
• ➖ Adds policy surface area and ongoing maintenance for the pinned toolchain
• ➖ Not necessary to fix the core issue (EOL minimum) addressed by this PR

3. Rely on CI workflow `setup-go` pin only

• ➕ No published API/consumer constraint change
• ➖ Does not fix the published module’s minimum Go requirement
• ➖ Does not prevent consumers from being required to use an EOL Go version

Recommendation: Keep the PR’s approach: raising the go directive to 1.25.0 is the minimal, most compatibility-preserving way to remove an EOL consumer floor while staying within supported Go versions. Consider adding a toolchain directive only if you want to standardize the compiler version beyond the minimum floor.

Files changed (1) +1 / -1

Other (1) +1 / -1

go.modBump module 'go' directive to 1.25.0 +1/-1

Bump module 'go' directive to 1.25.0

• Updates the published module’s minimum required Go version from 1.24.0 to 1.25.0, ensuring consumers and auto-toolchain selection no longer rely on an EOL release.

sdk-go/go.mod

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

1. Regeneration restores EOL floor ✓ Resolved 🐞 Bug ≡ Correctness

Description

The PR raises sdk-go/go.mod to Go 1.25, but codegen/render_go.py still unconditionally writes
go 1.24.0 whenever the SDK is regenerated. The next regeneration can therefore revert the
published SDK's consumer floor to the EOL release this PR is intended to remove.

Code

sdk-go/go.mod[3]

+go 1.25.0

Evidence

The changed module directive establishes the intended 1.25.0 floor, but the repository's generator
writes the same file with a conflicting hard-coded 1.24.0 directive. The generator comments
explicitly direct maintainers to rerun generation, making this an active overwrite path rather than
dead code.

sdk-go/go.mod[3-3]
codegen/render_go.py[80-90]
codegen/render_go.py[97-98]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
This change raises the checked-in SDK module floor to Go 1.25.0, but the generator overwrites `sdk-go/go.mod` with Go 1.24.0 during regeneration. A later generated release can silently undo this fix.

## Issue Context
The generator opens `sdk-go/go.mod` and emits a hard-coded `go 1.24.0` directive. Keep generated output and the checked-in module floor consistent, and ensure regeneration cannot restore the EOL floor.

## Fix Focus Areas
- codegen/render_go.py[84-90]
- sdk-go/go.mod[3-3]

Update the generator to emit Go 1.25.0 (or derive the version from one source of truth), then regenerate or verify the SDK module and add a regression check if appropriate.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context used

✅ REVIEW.md

Review mode: 🚀 Fast: This is a single-line, localized go.mod toolchain-floor change with low logical density and no independent edit sites; its impact is straightforward to assess in one light pass.

Tip of the day

💡 Did you know, you can ask Qodo to dismiss a finding you disagree with, with your reason on record

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[cursor]

Risk: low. Left a non-blocking comment because Cursor Bugbot and Cursor Security Agent both skipped, so the required automated review signals did not complete successfully. Human review is needed; no reviewers were assigned.

  

_{Sent by Cursor Approval Agent: Pull Request Router and Approver}

[qodo-code-review]

Qodo Fixer

🍒 Ready to be cherry-picked — ✅ Merged (0) · ☑ Fixed (1)

🔗 Fix PR: #60

This fix PR was closed automatically. Its branch is preserved so you can cherry pick the changes into the original PR.

Prompt for coding agent

This is an automated fix prepared on a separate branch (#60). It is NOT applied to this PR.
To use it: review Fix PR #60 (https://github.com/wave-av/sdks/pull/60), evaluate each change critically against your local context, and cherry-pick the changes that are correct into this branch. Do not accept them blindly.

Process — 1 fixed

• ☑ Fixed: Regeneration restores EOL floor

[macroscopeapp]

Approvability

Verdict: Needs human review

This is an explicitly breaking change (raising minimum Go version) that affects all SDK consumers. The code change is simple, but the sdk-owners team should review to confirm timing and consumer communication for this breaking dependency bump.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_4ccb642f-5418-4710-a6fa-968fa9ce783b)

[yakimoto]

Changelog gap flagged in review — valid, fixed in 86ded9d. Same miss as on the sibling public repo in this batch (wave-av/dispatch-edge#48): a change that raises what consumers need in order to build the published SDK shipped without an Unreleased entry.

The entry now states the breaking condition (older or pinned toolchains, and GOTOOLCHAIN=off, hard-fail), the escape hatch (GOTOOLCHAIN=auto handles it), why 1.25 and not 1.26 — oldest release still receiving security fixes, so the supported consumer window stays as wide as it can while clearing EOL — and that nothing downstream needs more: after the bump the highest go requirement in the entire module graph is this module itself (x/sync and x/sys sit at 1.24.0).

It also records the distinction that keeps this PR separate from #26, because it is the part most likely to be re-derived wrongly later: the go-version: "1.22" workflow pin was never the operative toolchain. Run 27102642727 on main logs setup-go installing go1.22.12, then GOTOOLCHAIN='auto' → go: downloading go1.24.0 — the toolchain switched itself up to what this directive demanded. Both versions are EOL, so the finding held either way, but a floor that ships inside go.mod cannot be fixed by a workflow change. #26 fixes the pin; this fixes the floor. Different files, no conflict, land both.

[yakimoto]

@macroscopeapp was right, and this is now fixed at the root rather than worked around.

The concern, confirmed

the codegen script reportedly still hardcodes Go 1.24.0, so SDK regeneration could revert this fix

Verified: codegen/render_go.py:87 wrote the literal "go 1.24.0\n\n". And it is stronger than "could revert" — sdk-go/go.mod is generated output, and the generator rewrites the go directive on every render (its own comment says it emits the directive deliberately so a regen does not drop it). So the original diff was editing the artifact and leaving the generator authoritative: the floor would have read as fixed in the tree and regressed the moment anyone ran codegen/generate.py.

The fix (ed32763)

The version is now a single named constant beside MODULE:

GO_VERSION = "1.25.0"
...
f"go {GO_VERSION}\n\n"

so the generator and its artifact cannot drift apart again.

Proven, not asserted

I ran the real codegen/generate.py (not a simulation) and diffed the whole tree:

• regenerated sdk-go/go.mod reads go 1.25.0
• sdk-go/ does not appear in the diff at all — the regenerated output is byte-identical to what this PR already committed

That is the receipt the concern actually asked for: generator and artifact now agree, demonstrated by rendering rather than by reading.

CHANGELOG.md records that the bump is applied in the generator, since this repo is public and the distinction matters to anyone regenerating.

One thing found and deliberately NOT folded in

.github/workflows/{test-go,release-go}.yml both pin go-version: "1.22" — two EOL generations below the new floor. They are inert for correctness: GOTOOLCHAIN=auto only switches up, which is exactly why CI stayed green while the module was on 1.24 (setup-go installed 1.22.12 and the toolchain upgraded itself). But they are a trap under GOTOOLCHAIN=off and they misreport what we test against.

Filed as #61 rather than folded in here, to keep this PR single-purpose and green while it is blocked on review.

Note on the head move

This pushes a new commit, so any completed review is now against the previous head. That is deliberate — the blocking concern was on this exact point, and it cannot be resolved without a new commit. Re-review welcome.