mirror of
https://github.com/hanzokv/go.git
synced 2026-09-24 00:31:51 +00:00
zeekay
ba01baa778
First real runs on this fleet turned up three things the workflows had been getting for free from GitHub's hosted image. golangci-lint had no setup-go step. The linter shells out to `go` to load packages, and the job image does not carry a toolchain on PATH, so it exited on "go command required, not found" without reading a file. It sets up Go from go.mod now, like every other job here. doctests ran setup-go before checkout, so go.mod was not on disk when the action looked for it and the module cache degraded to a permanent miss. Checkout goes first. The e2e proxy builder was pinned to golang:1.24-alpine while go.mod requires 1.26.4. The official golang images set GOTOOLCHAIN=local, which makes the image the authority and refuses a newer directive, so `go mod download` stopped the compose build and took both docker.start and docker.e2e.start with it. The base moves up to 1.26-alpine; the version stays declared in exactly one place, go.mod, with the image as its floor. govulncheck is reporting three standard-library advisories against this module. That is a real finding and it stays visible.
Maintenance Notifications
Seamless Redis connection handoffs during cluster maintenance operations without dropping connections.
Cluster Support
Cluster notifications are now supported for ClusterClient!
- SMIGRATING:
["SMIGRATING", SeqID, slot/range, ...]- Relaxes timeouts when slots are being migrated - SMIGRATED:
["SMIGRATED", SeqID, src host:port, dst host:port, slot/range, ...]- Reloads cluster state when slot migration completes
Note: Other maintenance notifications (MOVING, MIGRATING, MIGRATED, FAILING_OVER, FAILED_OVER) are supported only in standalone Redis clients. Cluster clients support SMIGRATING and SMIGRATED for cluster-specific slot migration handling.
Quick Start
client := redis.NewClient(&redis.Options{
Addr: "localhost:6379",
Protocol: 3, // RESP3 required
MaintNotificationsConfig: &maintnotifications.Config{
Mode: maintnotifications.ModeEnabled,
},
})
Modes
ModeDisabled- Maintenance notifications disabledModeEnabled- Forcefully enabled (fails if server doesn't support)ModeAuto- Auto-detect server support (default)
Configuration
&maintnotifications.Config{
Mode: maintnotifications.ModeAuto,
EndpointType: maintnotifications.EndpointTypeAuto,
RelaxedTimeout: 10 * time.Second,
HandoffTimeout: 15 * time.Second,
MaxHandoffRetries: 3,
MaxWorkers: 0, // Auto-calculated
HandoffQueueSize: 0, // Auto-calculated
PostHandoffRelaxedDuration: 0, // 2 * RelaxedTimeout
}
Endpoint Types
EndpointTypeAuto- Auto-detect based on connection (default)EndpointTypeInternalIP- Internal IP addressEndpointTypeInternalFQDN- Internal FQDNEndpointTypeExternalIP- External IP addressEndpointTypeExternalFQDN- External FQDNEndpointTypeNone- No endpoint (reconnect with current config)
Auto-Scaling
Workers: min(PoolSize/2, max(10, PoolSize/3)) when auto-calculated
Queue: max(20×Workers, PoolSize) capped by MaxActiveConns+1 or 5×PoolSize
Examples:
- Pool 100: 33 workers, 660 queue (capped at 500)
- Pool 100 + MaxActiveConns 150: 33 workers, 151 queue
How It Works
- Redis sends push notifications about cluster maintenance operations
- Client creates new connections to updated endpoints
- Active operations transfer to new connections
- Old connections close gracefully