[rowanseymour]

Summary

Updates vkutil from v0.26.0 to v0.30.0, so the Valkey pool gets default connect, read and write timeouts. Previously a half-open connection could block a request indefinitely.

Changes

• go.mod / go.sum: bump github.com/nyaruka/vkutil to v0.30.0. No code changes were needed:
  • test database claims are already coordinated (required since v0.27.0)
  • RateLimiter (changed in v0.29.0) isn't used
• The pool is still created with vkutil.NewPool(cfg.Valkey, vkutil.WithMaxActive(16)) and now picks up the default timeouts. Helpsites only issues PING, GET and SET, with no blocking commands or scripts, so the default read timeout needs no override.

Test plan

• go build ./... and go vet ./...
• go test ./... in the devcontainer

[claude]

Reviewed: this is a dependency-only bump (vkutil v0.26.0 → v0.30.0) and I found no issues.

• Helpsites calls vkutil only through vkutil.NewPool(cfg.Valkey, vkutil.WithMaxActive(16)) (runtime/runtime.go:39) and assertvk in the testsuite. testsuite/valkey.go already calls assertvk.Coordinate(16, 17, 63), so the v0.27.0 claim-coordination requirement is met.
• Runtime Valkey use is just GET/SET/PING (core/search/search.go, cmd/connections.go), so the new default read timeout won't cut off any long-running or blocking command.
• Only the vkutil lines change in go.mod/go.sum, so v0.30.0 doesn't raise any other shared requirements (e.g. redigo, gocommon). CI building with -mod=readonly will confirm that.

Possible follow-up, not a blocker: there's no test that the pool times out against an unresponsive server. The fix depends entirely on upstream defaults, so a later vkutil change could quietly undo it. A short test with a listener that accepts connections and never replies would pin the behaviour down.

🤖 Generated with Claude Code