Repository navigation
build(deps): Bump github.com/stretchr/testify from 1.11.1 to 1.12.1 - #1411
Closed
dependabot[bot] wants to merge 1 commit into
Closed
dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
dependabot
Bot
added
the
dependencies
dependabot
Bot
requested review from
QuantumExplorer and
lklimek
as code owners
August 18, 2026 16:33
dependabot
Bot
added
the
dependencies
Collaborator
Dependency Audit —
|
| Direct | github.com/stretchr/testify 1.11.1 → 1.12.0 (minor, test-only) |
| Indirect | github.com/stretchr/objx 0.5.2 → 0.5.3 |
| Removed | github.com/pmezard/go-difflib (vendored into testify internal/) |
| Files touched | go.mod, go.sum — nothing else |
| Upstream commits | 115 |
Diff Integrity — CLEAN
That +7,804 line diff looks alarming right up until you see what it is: testify vendored go-spew and go-difflib into internal/ because both are unmaintained upstream (stretchr/testify#1708, stretchr/testify#1827). Vendoring is a lovely place to hide a payload, so I diffed it against upstream byte-for-byte rather than taking the changelog's word for it:
internal/difflib/vspmezard/go-difflib@5d4384e— zero added code lines. Everything is deletions (deadNewMatcherWithJunk,calculateRatio, context-diff) plus godoc reflow. LICENSE preserved (differs only by a missing trailing newline).internal/spew/vsdavecgh/go-spew— zero functional changes across all 8 files. Every single "addition" is godoc block-comment reformatting into gofmt list style.bypass.go/bypasssafe.go— theunsafereflection machinery, i.e. the juiciest injection target in the whole package — are byte-identical. LICENSE identical.- Tag integrity:
v1.12.0→001eb7946baf451879253643e4ce4b38eaa0d4a7, matching the top commit in the release notes. No moved tag. - Checksums:
go.sumentries matchsum.golang.orgexactly for both modules. - No new network calls, no install/lifecycle hooks, no obfuscation. The CI changes are pin-hardening (CI: upgrade GitHub Actions and pin hashes stretchr/testify#1883 pins action SHAs, CI: add check of GitHub Action pinned hashes against tag stretchr/testify#1885 adds a hash-vs-tag check) — a security improvement, not a regression.
objx 0.5.3 is even quieter: zero production .go files changed. It merely dropped its own testify dependency to break the dependency cycle.
Known Vulnerabilities
OSV.dev returns empty for testify, objx, and go-difflib. No CVEs, no advisories, at any version.
Codebase Impact
go list -deps ./cmd/tenderdash → 0 testify packages. It never reaches the node binary; blast radius is test code only.
The behaviour changes in 1.12.0 that could plausibly bite a consumer, checked against this repo:
| Change | Our exposure |
|---|---|
*AssertionFunc types become aliases (#1563) |
0 usages |
IsIncreasing et al. now Fail on non-collections (#1787) |
0 usages |
suite validates method signatures (#1665) |
13 suite files, 0 with invalid signatures |
mock.AssertExpectationsForObjects errors instead of panicking on a bad type (#1795) |
strictly safer than before |
mock mutating-stringer matching reverted to pre-1.11.0 (#1786) |
mocks are mockery-generated; tests (01)–(05) green |
Verified by compiling, not by squinting:
go build -buildvcs=false ./... && go test -buildvcs=false -run '^$' -count=1 \
./internal/statesync/... ./internal/consensus/... ./internal/blocksync/... \
./internal/p2p/... ./types/... ./rpc/... ./internal/mempool/... ./light/...
→ exit 0 — whole module builds, 41 test binaries link clean against 1.12.0
About that red CI
govulncheck is pre-existing and has nothing whatsoever to do with testify. All 6 findings are in the Go standard library at go1.26.5, and every one of them says Fixed in: go1.26.6:
| ID | Package |
|---|---|
| GO-2026-6218 | net/url |
| GO-2026-6091 | html/template |
| GO-2026-6090 | crypto/tls |
| GO-2026-6089 | net/http |
| GO-2026-5972 | encoding/asn1 |
| GO-2026-5026 | net/http |
The proof it isn't us: a plain push to v1.7-dev (run 32049450842) produces the byte-identical set of 6, with no dependabot anywhere near it. The job is also red on master and on human PRs #1413 and #1414.
Root cause is the toolchain pin — go 1.26.5 in go.mod and go-version: "1.26.5" in .github/workflows/govulncheck.yml, with GOTOOLCHAIN=local. That fix belongs in its own PR: bump both to 1.26.6. A test-assertion library can neither cause nor cure a crypto/tls bug, so blocking this PR on it is just punishing the messenger.
The rest of the red is equally innocent:
tests (00)— ran 6h00m15s thenThe operation was canceled: job timeout / hang.tests (01)–(05)all passed, and that's where the testify-facing code actually compiles and runs.golangci-lintandBuild (amd64, linux)— bothThe operation was canceledas well. Infra cancellation, not findings.
Nothing red on this PR is attributable to this bump.
Risk Assessment
Safe. Test-only dependency, absent from the shipped binary, no known vulnerabilities, verified-clean vendoring, checksum-database-confirmed hashes, and the entire module compiles against it.
Recommendations
- Merge once CI is green. The branch is 31 commits behind
v1.7-dev, so I've asked dependabot to rebase. - Separate PR: bump the Go toolchain
1.26.5→1.26.6ingo.modand.github/workflows/govulncheck.yml. That clears all 6 stdlib findings repo-wide and unblocks build(deps): Bump golang.org/x/crypto from 0.54.0 to 0.55.0 #1410, build(deps): Bump github.com/stretchr/testify from 1.11.1 to 1.12.1 #1411, build(deps): Bump golang.org/x/net from 0.57.0 to 0.58.0 #1412 and the human PRs in one shot. - Worth a look separately: the
tests (00)shard burning a full 6 hours before the runner gives up is a lot of CI time to spend on a hang.
🤖 Co-authored by Claudius the Magnificent AI Agent
Collaborator
|
@dependabot rebase |
Contributor
Author
|
Sorry, only users with push access can use that command. |
Collaborator
|
@dependabot rebase |
Bumps [github.com/stretchr/testify](https://github.com/stretchr/testify) from 1.11.1 to 1.12.1. - [Release notes](https://github.com/stretchr/testify/releases) - [Commits](stretchr/testify@v1.11.1...v1.12.1) --- updated-dependencies: - dependency-name: github.com/stretchr/testify dependency-version: 1.12.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
changed the title
dependabot
Bot
force-pushed
the
dependabot/go_modules/github.com/stretchr/testify-1.12.0
branch
from
August 25, 2026 09:21
ad67647 to
f7aa443
Compare
1 of 5 tasks
Contributor
Author
|
Superseded by #1422. |
dependabot
Bot
deleted the
dependabot/go_modules/github.com/stretchr/testify-1.12.0
branch
August 25, 2026 16:34
lklimek
added a commit
that referenced
this pull request
Aug 26, 2026
govulncheck fails identically on v1.7-dev and every open PR branch (#1412, #1411, #1410) with 6 Go standard-library findings, all "Found in: go1.26.5 / Fixed in: go1.26.6": - GO-2026-6218 (net/url) - GO-2026-6091 (html/template) - GO-2026-6090 (crypto/tls) - GO-2026-6089 (net/http, x2) - GO-2026-5972 (encoding/asn1) Reachable from our TLS/RPC/HTTP server and Dash Core client paths (same call sites as PR #1395). Bumping the pinned toolchain from 1.26.5 to 1.26.6 turns govulncheck green everywhere at once and unblocks #1412, #1411, #1410. Mirrors PR #1395's pattern (1.26.4 -> 1.26.5): pure patch-release toolchain swap, no language/API changes, same 16 files touched (go.mod, CI workflow go-version pins, Dockerfiles, docs). Verified locally with go1.26.6: go build ./... succeeds, and govulncheck ./... reports 0 vulnerabilities (down from 6). Claude-Session: https://claude.ai/code/session_01RoXmbFrVf1BqVW1BHZv6Va Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
lklimek
added a commit
that referenced
this pull request
Sep 7, 2026
* chore(deps): bump Go to 1.26.6 (#1417) govulncheck fails identically on v1.7-dev and every open PR branch (#1412, #1411, #1410) with 6 Go standard-library findings, all "Found in: go1.26.5 / Fixed in: go1.26.6": - GO-2026-6218 (net/url) - GO-2026-6091 (html/template) - GO-2026-6090 (crypto/tls) - GO-2026-6089 (net/http, x2) - GO-2026-5972 (encoding/asn1) Reachable from our TLS/RPC/HTTP server and Dash Core client paths (same call sites as PR #1395). Bumping the pinned toolchain from 1.26.5 to 1.26.6 turns govulncheck green everywhere at once and unblocks #1412, #1411, #1410. Mirrors PR #1395's pattern (1.26.4 -> 1.26.5): pure patch-release toolchain swap, no language/API changes, same 16 files touched (go.mod, CI workflow go-version pins, Dockerfiles, docs). Verified locally with go1.26.6: go build ./... succeeds, and govulncheck ./... reports 0 vulnerabilities (down from 6). Claude-Session: https://claude.ai/code/session_01RoXmbFrVf1BqVW1BHZv6Va Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> (cherry picked from commit 0a7a33e) * ci(lint): bump golangci-lint from v2.12 to v2.13 golangci-lint v2.12.2 (the latest v2.12.x, matching the current floating `version: v2.12` selector) panics rather than reporting findings when analyzing this codebase under Go 1.27.1: the bundled staticcheck analyzer (honnef.co/go/tools@v0.7.0) crashes its SSA/IR builder with "unexpected expr: *ast.KeyValueExpr" while building IR for the stdlib package internal/poll. Confirmed deterministic (reproduced twice) and not a stale-binary artifact (rebuilt golangci-lint v2.12.2 from source with the go1.27.1 toolchain itself, same panic). Isolating the culprit with --disable=staticcheck makes the panic disappear and returns 0 issues, but disabling staticcheck in CI is rejected as a fix: it is the linter catching the QF1008 class, and turning it off to land a version bump would trade a real gate for a green tick. golangci-lint v2.13.0 shipped 2026-08-19, the same day as Go 1.27.0 — the 2.13 line is Go 1.27-compatible where 2.12 predates Go 1.27 entirely. Measured v2.13.2 (the latest v2.13.x) built fresh with both toolchains: no panic and 0 --new-from-rev findings at go1.26.6 and at go1.27.1. The two changes are independent, so this commit lands ahead of and does not depend on the Go 1.27.1 bump that follows it — every intermediate commit in this branch keeps the lint job runnable. Kept the existing floating-minor pin convention (`v2.13`, not an exact `v2.12.2`-style pin): the crash was caused by the minor version predating Go 1.27, not by floating within a minor, so an exact pin would have failed identically and there is no reason to change the convention in response to a problem it did not cause. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019gAC8rAzQagn5sgDxUJNjj * chore(mockery): bump to v3.7.4 and regenerate The `check-mocks` CI job pins `mockery=3.7.0` (released 2026-03-06, five months before Go 1.27.0). Under a go1.27.1 toolchain, mockery 3.7.0 fails outright rather than producing a diff: internal error: package "github.com/dashpay/tenderdash/libs/ds" without types was imported from "github.com/dashpay/tenderdash/libs/store" This is mockery's bundled golang.org/x/tools/go/packages loader failing to attach type information to a transitively-imported package when driven by the newer toolchain — not a defect in this repository's source. Reproduced locally under the exact conditions CI runs (GOTOOLCHAIN=local, the go1.27.1 binary setup-go installs, no auto-download); the CI log itself can't show this, since the generation step runs `make mockery 2>/dev/null` and discards stderr — anyone hitting this in CI needs to reproduce it locally to see anything past "exit code 2". mockery v3.7.4 (released 2026-08-23, four days after Go 1.27.0) fixes it: same reproduction conditions, clean exit. Measured it under both go1.26.6 and go1.27.1 and got byte-identical regenerated output either way — the interface{}->any / parameter-naming differences below come entirely from mockery's own codegen version, not from which Go toolchain drives it. That's what makes this commit stand on its own ahead of the Go 1.27.1 bump that follows it in this branch, rather than being a consequence of it. Bumped both pin sites: check-generated.yml's MOCKERY and scripts/mockery_generate.sh's VERSION. The version bump and the regenerated mocks can't be split into separate commits: CI regenerates and diffs in the same step, so a pin bump without regenerated mocks leaves check-mocks red (diff appears), and regenerated mocks without the pin bump leaves it red too (CI regenerates with 3.7.0 and hits the error above again). Regenerated all mocks under mockery v3.7.4 (`make mockery`). The diff is mechanical and cosmetic only, inspected file-by-file rather than trusted from the diffstat: every change is either `interface{}` -> `any` in generated _Expecter method signatures (Go 1.18+ built-in alias, identical type), or a generated parameter name recovering the interface's real source name where 3.7.0 fell back to a generic placeholder (`v`, `vs`, `context1`). No method set changed, no mock behavior changed. Confirmed behaviorally rather than just by reading the diff: `go build ./...` is clean with the regenerated mocks in place, and `go test ./internal/consensus/... -count=1` is green (one run hit the already-known-flaky TestByzantinePrevoteEquivocation from this task's original brief; a second run was clean, consistent with that test's known ~18% flake rate and unrelated to this change). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019gAC8rAzQagn5sgDxUJNjj * test(rpc): close idle client connections in TestMaxOpenConnections Go 1.27 changed HTTP/1 Response.Body.Close() to automatically drain any unread content, up to a conservative limit, to allow the underlying connection to be reused (see the "net/http" section of the Go 1.27 release notes). TestMaxOpenConnections never reads its response bodies before closing them, so under Go 1.27 the requests it makes leave healthy, idle keep-alive connections sitting in the client's pool instead of being closed outright as they were under Go 1.26. Those idle connections keep the corresponding server-side handler goroutines parked in a read wait, which the leaktest check registered at the top of the test flags as leaked: leaktest: leaked goroutine: ... [IO wait]: ... net/http.(*conn).serve ... created by net/http.(*Server).Serve This is not a defect in the server's shutdown path, and reading the response body before closing it does not fix it — 1.27 already drains it for you, which is the entire behavior change; an explicit drain reaches the identical end state (healthy, pooled connection, server goroutine still parked). Confirmed by testing it directly: draining the body explicitly still leaks 100% of the time under go1.27.1. Fixed by sharing one Client across the request goroutines (http.Client is safe for concurrent use) and calling its CloseIdleConnections after they've all completed, before the leaktest check fires. This does not change what the test measures: instrumented it locally to confirm peak concurrent open connections still reaches exactly `max` with the shared client, matching the per-goroutine-client version — concurrent in-flight requests still each need their own connection regardless of pooling, since pooling only affects connections after they go idle. Verified at both go1.26.6 and go1.27.1 (5 consecutive runs each, clean at both, plus one run with -race): this fix is a general test correctness improvement, not conditional on either toolchain, which is why it lands ahead of the Go 1.27.1 bump in this branch rather than after it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019gAC8rAzQagn5sgDxUJNjj * test(rpc): assert on our own error family, not stdlib phrasing TestRPCParams and TestParseURI/Decode asserted on the stdlib's exact wording for a malformed json.Number ("invalid number literal" / "invalid number"). That wording changed between Go versions — under Go 1.27 it reads "cannot unmarshal string ... into Go value of type json.Number: invalid syntax" instead — which breaks the assertion even though the actual behavior (the malformed input is still rejected, with the same RPC error code) hasn't changed at all. Traced the code path rather than guessing a new substring: RPCFunc.parseParams wraps every parameter-decode failure via invalidParamsError(), which always builds an rpctypes.RPCError with Code: CodeInvalidParams and Message: CodeInvalidParams.String() — our own constant, literally "Invalid params", unconditionally. Only RPCError.Data ever carries the wrapped stdlib error text. Asserting on "Invalid params" instead of the stdlib phrase pins our own contract (this rejection landed in the invalid-params family) rather than a description we don't own and that a future Go release is free to reword again. This is also a stronger assertion than the one it replaces: the old substring match could not distinguish an invalid-params rejection from any other error that happened to contain the same words, whereas the new one names the specific error family. Checked for the same pattern elsewhere before touching only these two sites: types/genesis_test.go:164 pins a different stdlib JSON error string ("cannot unmarshal string into Go struct field ... of type int64"), but that's the struct-field type-mismatch error class, not the json.Number-literal class this Go release changed, and it already passes clean under go1.27.1 (16/16 subtests) — confirmed by running it, not assumed. Two sites, not a repo-wide problem. Verified at both go1.26.6 and go1.27.1 (all TestRPCParams and TestParseURI subtests green at both, full package test suite green at go1.26.6): version-neutral, so this lands ahead of the Go 1.27.1 bump rather than after it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019gAC8rAzQagn5sgDxUJNjj * chore(deps): bump Go to 1.27.1 Follow-on to the previous two commits: with golangci-lint on v2.13 (previous commit), it is safe to move the pinned Go toolchain past 1.26.6 to 1.27.1. This is a minor-version bump, not a patch bump — Go 1.26.6 -> 1.27.1 crosses a Go release boundary, so the "no language/API changes" claim that held for the 1.26.5 -> 1.26.6 patch swap does not carry here and was verified fresh rather than assumed. Verified for the full three-commit stack (this commit on top of the golangci-lint v2.13 bump on top of the Go 1.26.6 cherry-pick): - go build ./... clean. - go vet ./... reports the same 4 findings, byte-for-byte, before and after this commit (3x fmt.Errorf %q in test/e2e/pkg/testnet.go, 1x IPv6 address format in dash/quorum/nodeid_resolver.go) — all pre-existing and unrelated to this change. No new vet strictness under Go 1.27. - govulncheck ./... reports the same finding sets before and after: 0 stdlib vulnerabilities affecting our code, and the same 4 dependency-only findings our code doesn't call (GO-2026-6355, GO-2026-6354, GO-2026-6303, GO-2026-5932) on both sides. - golangci-lint v2.13.2 (what the v2.13 selector resolves to) with --new-from-rev=origin/v1.7-dev: 0 issues, no panic. - go test ./internal/consensus/... -count=1, twice: both green (61.1s, 69.0s) on the final three-commit stack. - GOTOOLCHAIN=auto correctly resolves and downloads go1.27.1 from this module's go.mod, confirmed via `go version` run from inside the module. What moved, reported rather than fixed: - golangci-lint's gofmt formatter (.golangci.yml formatters.enable) flags one pre-existing, untouched file — internal/rpc/core/ mempool.go:149 — as differently formatted under Go 1.27.1's bundled gofmt than under 1.26.6's (a multi-value return with a composite literal inside a select/case reindents differently). --new-from-rev correctly excludes it since the affected line isn't part of any diff in this branch, so no CI gate fails on it. It is an active check, not an absent one — it simply isn't triggered against a line this branch touches. Left unformatted: out of scope for a toolchain-pin change. - During earlier measurement (not the two required runs above, both of which were clean), one go1.27.1 run of `go test ./internal/consensus/...` hit a failure in TestPoC_HeightVoteSet_UnboundedRoundAllocation (retained 308 bytes per message against a <149 threshold), not one of the two previously-known flaky tests in this package. Isolated reruns of just this test passed 5/5 under go1.27.1 and 3/3 under go1.26.6. The 1.26.6 baseline never ran this test under equivalent full-package concurrent load, so this is not a like-for-like comparison between Go versions — left unresolved and not claimed to be version-related. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019gAC8rAzQagn5sgDxUJNjj * style: reformat mempool.go for Go 1.27's gofmt Go 1.27's gofmt reindents a multi-value return containing a composite literal inside a select/case block differently than Go 1.26's gofmt does: the composite literal body and the trailing fmt.Errorf continuation drop one level of indentation. Formatted here with the go1.27.1 toolchain's own gofmt -w -s (`go env GOROOT`'s bin/gofmt under this branch's now-pinned toolchain) — the same flags `make format`'s gofmt step uses; `-s` (simplify) produces an identical diff to plain gofmt here, so it isn't smuggling in any rewrite beyond the reindent. Ran the full-repository gofmt -l -s sweep under go1.27.1 first, using make format's own exclusions (skip *.pb.go, *pb_test.go, .git) rather than fixing only the single file golangci-lint's filtered lint run had named: internal/rpc/core/mempool.go was the only file the sweep flagged, before and after -s. Did not run the rest of `make format` (golines, goimports) since those are separate tools operating on unrelated lines (line-wrapping, import grouping) — out of scope for a pure gofmt-drift fix. This repository has no standalone gofmt gate that this drift was failing: .golangci.yml's `formatters.enable` list does include gofmt (a distinct section from `linters.enable` in golangci-lint v2's config schema — it is an active check, not an absent one), but the one finding it produced was on a line outside any diff in this branch, so `--new-from-rev` filtered it and no CI gate was failing. `make format` itself writes rather than checks, so it enforces nothing on its own either. This commit removes latent formatting drift ahead of it mattering, not a fix for a red gate. Confirmed asymmetric in both directions: after this reformat, `gofmt -l -s` is clean under go1.27.1 (this branch's pinned toolchain) but go1.26.6's gofmt now wants the same lines re-indented back the other way. Anyone building this file with a local Go 1.26.x toolchain and running gofmt/make format against it will see a diff again — expected, since the two Go versions' gofmt disagree on this construct in both directions, and this branch is pinned to 1.27.1. No logic changes: the diff is pure reindentation of already-existing lines, confirmed via `gofmt -d` before applying. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019gAC8rAzQagn5sgDxUJNjj --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps github.com/stretchr/testify from 1.11.1 to 1.12.1.
Release notes
Sourced from github.com/stretchr/testify's releases.
... (truncated)
Commits
959dbdaMerge pull request #1935 from harryzcy/yaml-update9bb7176Update go.yaml.in/yaml/v3 to v3.0.5001eb79Merge pull request #1905 from Kentzo/patch-1ad40f38Merge pull request #1906 from stretchr/dependabot/github_actions/actions/chec...3bae017build(deps): bump actions/checkout from 6.0.2 to 6.0.3f8c01f3mock: Mock.Return does not exist anymore12f8b56Merge pull request #1563 from stretchr/make-AssertionFunc-types-aliasesa11649eassert: make *AssertionFunc type just aliasesdc20f41Merge pull request #1890 from stretchr/dolmen/codegen-modernize098f8d7_codegen: use strings.Builder