security: raise the published Go SDK minimum off an EOL toolchain (1.21 → 1.25)

[yakimoto]

One line. sdk/go/go.mod: go 1.21 → go 1.25.

Why

go 1.21 is the minimum Go version this published module demands of everyone who installs it, and Go 1.21 went end-of-life on 2024-08-13 — nearly two years ago. Supported Go today is 1.25 and 1.26, nothing older.

github.com/wave-av/dispatch-edge/sdk/go is live on the module proxy (latest v0.7.0, 2026-05-30, 8 published versions), so this is a real advertised floor, not a private detail. 1.25 is chosen over 1.26 deliberately: it is the oldest release still receiving security fixes, which keeps the consumer window as wide as it can be while no longer pointing at an EOL toolchain.

Verification — and why it had to be done by hand

This repo has no CI that compiles Go. All four workflows (_checks, foundation-gate, issue-ops-triage, public-repo-guard) were checked; none references setup-go, go build, or go test. So a green check on this PR will not tell you the module still builds — nothing here builds it.

Run locally against go1.26.4 instead:

go build ./...   ok
go vet ./...     ok
go test ./...    ok   —  "no test files"

That last line is not a formality, it is the finding: the published SDK has no tests at all.

The directive was also mutation-checked, so this isn't a cosmetic edit to a field nothing reads:

go 1.99  ->  go: go.mod requires go >= 1.99 (running go 1.26.4; GOTOOLCHAIN=local)
go 1.25  ->  builds clean

It fails closed on an unsatisfiable version and passes on a satisfiable one — the directive is load-bearing.

Scope — what this deliberately does not fix

This raises the advertised floor. It does not address the larger thing found while measuring it: this published copy has drifted substantially from its source in the private wave-av/wave-dispatch repo — dispatch.go is 95 lines here against 411 there, and verify.go / verify_test.go are absent — while being the copy consumers actually go get. The copy that CI does build and test declares a vanity module path that does not resolve.

That is tracked separately (wave-av/wave-dispatch#466) rather than widened into this diff. Raising an EOL floor is worth landing on its own, and shouldn't wait on a curation decision.

Companion PR on the source repo: wave-av/wave-dispatch#465.

🤖 Generated with Claude Code

---

Note

Low Risk
Metadata-only change to the module go directive and changelog; no runtime or SDK API behavior changes, though consumers on Go < 1.25 may need a toolchain upgrade.

Overview
Bumps the published Go SDK’s minimum toolchain in sdk/go/go.mod from 1.21 to 1.25, so consumers of github.com/wave-av/dispatch-edge/sdk/go no longer see an end-of-life Go floor. 1.25 is the oldest release still getting security fixes; no SDK source files change.

CHANGELOG.md documents this as BREAKING for Go SDK consumers on pinned or older toolchains (GOTOOLCHAIN=off fails until upgraded); default GOTOOLCHAIN=auto can fetch a suitable toolchain.

^{Reviewed by Cursor Bugbot for commit 4287ecf. Configure here.}

Note

Raise Go SDK minimum version from 1.21 to 1.25

Updates the go directive in go.mod to require Go 1.25+, moving off the EOL 1.21 toolchain. Risk: builds using Go < 1.25 will fail; this is a breaking change for consumers pinned to older toolchains.

^{Macroscope summarized 4287ecf.}

[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_4f8ba6c3-a846-4014-85fe-a90fd0a4884b)

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 34 minutes

Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: b32bfd3a-3b54-418d-8419-a52184fe4f1a

📥 Commits

Reviewing files that changed from the base of the PR and between 5a02817 and 4287ecf.

📒 Files selected for processing (2)

• CHANGELOG.md
• sdk/go/go.mod

---

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

[qodo-code-review]

PR Summary by Qodo

Raise Go SDK minimum version to Go 1.25 (from 1.21)

⚙️ Configuration changes ✨ Enhancement 🕐 Less than 5 minutes

AI Description

• Bump the published Go SDK's minimum supported Go version from 1.21 to 1.25.
• Align the module's advertised toolchain floor with currently supported Go releases.
• Ensure consumers fail fast on unsupported/EOL toolchains via go.mod version gating.

Diagram

graph TD
A(["SDK consumer"]) --> B["go install/build"] --> C["sdk/go/go.mod"] --> D{"Go >= 1.25?"} --> E["Build/install proceeds"]
D -->|"No"| F["Fail with version error"]
subgraph Legend
  direction LR
  _actor(["Actor"]) ~~~ _step["Process step"] ~~~ _dec{"Decision"}
end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Raise minimum to Go 1.26 instead

• ➕ Maximizes access to the latest language/runtime improvements and fixes
• ➕ Potentially reduces support surface across consumers sooner
• ➖ Narrower consumer compatibility window than necessary if 1.25 is still supported
• ➖ More likely to force upgrades for users pinned to the oldest supported toolchain

2. Keep go 1.21 but add policy/docs about supported versions

• ➕ Avoids breaking consumers pinned to Go 1.21
• ➕ Changes only documentation/policy, not build gating
• ➖ Does not enforce security posture; consumers can keep using an EOL toolchain silently
• ➖ Shifts risk to users and support channels rather than failing fast

3. Add a toolchain directive (e.g., toolchain go1.25.x) in addition to go 1.25

• ➕ Can improve developer experience by enabling automatic toolchain selection/download where supported
• ➕ Keeps the explicit minimum version gate while smoothing upgrades
• ➖ Adds another moving part (toolchain selection behavior) that may surprise some environments
• ➖ Still requires careful validation across developer setups and CI systems

Recommendation: Proceed with the current approach (raise go directive to 1.25). It cleanly enforces a non-EOL minimum while keeping the broadest compatibility window among supported Go releases. Consider a follow-up to add a toolchain directive only if the project wants auto-toolchain behavior; it’s not required to achieve the security/support goal.

Files changed (1) +1 / -1

Other (1) +1 / -1

go.modBump module minimum Go version to 1.25 +1/-1

Bump module minimum Go version to 1.25

• Updates the go.mod 'go' directive from 1.21 to 1.25, raising the minimum Go toolchain required by consumers of the published SDK module.

sdk/go/go.mod

[devin-ai-integration]

Devin Review found 3 potential issues.

[cursor]

Risk: low. Left a non-blocking comment — Cursor Bugbot and Cursor Security Agent both skipped (Bugbot hit a usage limit), so required automated review signals did not complete successfully and human review is needed. No reviewers were assigned because no eligible non-author reviewers were available.

  

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

[qodo-code-review]

Code Review by Qodo

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

1. Unnoted Go floor bump 🐞 Bug ⚙ Maintainability

Description

Raising sdk/go/go.mod to go 1.25 increases the module’s minimum supported Go version; consumers
pinned to older toolchains or environments with toolchain auto-download disabled will hit
build/import failures. The repo’s changelog/docs currently don’t call out this breaking
minimum-version change, increasing the chance of unexpected upgrade failures.

Code

sdk/go/go.mod[3]

+go 1.25

Evidence

The module’s go directive is now 1.25, which is a user-facing minimum for consumers. The
repository changelog is effectively empty beyond an Unreleased header, and the README install
tables list the Go install command but do not mention a minimum Go version, so this breaking
compatibility change is not currently communicated in-repo.

sdk/go/go.mod[1-3]
CHANGELOG.md[1-7]
README.md[68-83]
sdk/README.md[7-14]

Agent prompt

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

## Issue description
The PR raises the Go module minimum version to 1.25, which can break consumers using older Go toolchains or restricted environments. This compatibility change should be explicitly documented for release/upgrade clarity.

## Issue Context
The `go` directive in `go.mod` is a consumer-facing minimum. Current repo docs show `go get .../sdk/go` install instructions but do not state the minimum Go version, and the changelog has no Unreleased entry documenting this change.

## Fix Focus Areas
- sdk/go/go.mod[1-3]
- CHANGELOG.md[1-7]
- README.md[68-83]
- sdk/README.md[7-14]

## Suggested fix
- Add an `[Unreleased]` changelog entry noting: "Go SDK: raise minimum supported Go version to 1.25".
- Optionally add a short note near the Go install instructions in `README.md` and/or `sdk/README.md` stating the minimum required Go version (1.25).

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

---

Context used

Review mode: ⚖️ Balanced: This is a small, localized module-version change, but it changes a published SDK's minimum toolchain contract and therefore warrants a careful single-pass review rather than lite or skip.

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

[qodo-code-review]

Qodo Fixer

No findings are within the configured fix scope. To change which findings are fixed, adjust the setting on your Qodo configuration page.

[macroscopeapp]

Approvability

Verdict: Approved 4287ecf

This PR raises the minimum Go version in go.mod from 1.21 to 1.25 and documents the breaking change in CHANGELOG.md. No source code is modified - it's a mechanical version floor bump for security currency. The author owns both changed files.

^{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_40a20439-0af4-404f-8a88-f2b92e048412)

[yakimoto]

Three review findings, one of which was a genuine miss. Addressed in 4287ecf.

1. No changelog entry — VALID, fixed. Devin and qodo both caught it independently, and it was worse than an oversight: I wrote exactly this entry into the private source repo's changelog in the companion PR (wave-av/wave-dispatch#465) and omitted it here — the repo where consumers actually read it. Now under Unreleased, stating the breaking condition (older/pinned toolchains and GOTOOLCHAIN=off hard-fail), the escape hatch (GOTOOLCHAIN=auto fetches one, no action needed), and the 1.25-not-1.26 reasoning.

2. "The code uses nothing beyond the previously declared baseline" — correct, and that is the point. This is not a bump to adopt a language feature; it is a bump because 1.21 has been end-of-life since 2024-08-13 and the go directive is what this module advertises as its minimum to every consumer. Leaving it at 1.21 does not keep old toolchains safe, it keeps them sanctioned. 1.25 is the oldest release still receiving security fixes precisely so the window stays as wide as it can while clearing EOL. Now said explicitly in the changelog rather than only in the PR body.

3. "No CI job builds or tests the Go SDK, so the bump is unverified" — accurate, and it is the finding, not a defect of this PR. The PR description says the same thing and names the four workflows. It is why verification was done by hand on go1.26.4 (build/vet/test clean, test reporting no test files), and why the directive was mutation-checked (go 1.99 → requires go >= 1.99; 1.25 → clean) rather than assumed to be a field nothing reads.

That gap is tracked as wave-av/wave-dispatch#466, along with the larger thing behind it: this published copy has drifted hard from its source — dispatch.go is 95 lines here against 411 there, and verify.go/verify_test.go are absent — so the Go SDK we test and the Go SDK we ship are different artifacts. Deliberately not widened into a one-line EOL fix.