If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/redis/go-redis shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1d ago
• 38+ active contributors
• Distributed ownership (top contributor 21% of recent commits)
• BSD-2-Clause licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live redis/go-redis repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/redis/go-redis.

What it runs against: a local clone of redis/go-redis — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in redis/go-redis | Confirms the artifact applies here, not a fork | | 2 | License is still BSD-2-Clause | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of redis/go-redis. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/redis/go-redis.git
#   cd go-redis
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of redis/go-redis and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "redis/go-redis(\\.git)?\\b" \\
  && ok "origin remote is redis/go-redis" \\
  || miss "origin remote is not redis/go-redis (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(BSD-2-Clause)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"BSD-2-Clause\"" package.json 2>/dev/null) \\
  && ok "license is BSD-2-Clause" \\
  || miss "license drift — was BSD-2-Clause at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/redis/go-redis"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

go-redis is the official Redis client library for Go, providing a straightforward interface to interact with Redis servers (supporting Redis 8.0, 8.2, and 8.4). It implements comprehensive command support across strings, hashes, lists, sets, sorted sets, bitmaps, ACLs, and cluster operations, with built-in connection pooling, automatic retry logic (via dial_retry_backoff.go), and support for Redis Cluster and Sentinel topologies. Single-package monolith structure: root level contains core command implementations (acl_commands.go, bitmap_commands.go, cluster_commands.go, commands.go) paired with tests, supporting modules under auth/ directory, Docker setup via docker-compose.yml and dockers/, CI/CD workflows under .github/workflows/, and integration test examples scattered in root (async_handoff_integration_test.go, bench_test.go). No clear separation into subpackages; most logic lives at repository root.

Go developers building applications that need to integrate with Redis for caching, sessions, pub/sub messaging, or real-time data structures. Specifically: microservice teams using Redis Cluster, infrastructure engineers managing Sentinel deployments, and application developers leveraging async handoff patterns for background jobs.

Production-ready and actively maintained. The project is the official Redis Go client with comprehensive CI coverage (workflows for build, e2e tests, CodeQL analysis, doctests), v9 major version indicates stability, and extensive test files (acl_commands_test.go, bitmap_commands_test.go, etc.) paired with integration tests (async_handoff_integration_test.go). Last activity indicates ongoing maintenance.

Low risk for production use as the official client, but monitor: relatively lean direct dependency list (cespare/xxhash, uber/atomic) reduces supply-chain risk, however breaking changes may occur between minor versions given Redis 8.x evolution. The large codebase (3.8M lines of Go) means surface area for bugs, though CI testing against multiple Redis and Go versions mitigates this.

Active development focused on Redis 8.x compatibility (supporting 8.0, 8.2, 8.4 as listed in README), with integration testing against multiple Redis versions and Go versions (1.24, oldstable, stable). Likely ongoing work on command implementations, retry logic refinement, and cluster/Sentinel reliability given the presence of command_policy_resolver.go and reauth_credentials_listener.go.

Clone and test: git clone https://github.com/redis/go-redis.git && cd go-redis && go mod download && go test ./... . For integration tests, ensure a Redis instance is running (see docker-compose.yml: docker-compose up -d), then run go test -tags=integration ./... or use the GitHub Actions flow.

Daily commands: Local development with local Redis: docker-compose up -d (starts Redis), then go test ./... to run unit tests. For end-to-end: go test -run TestE2E ./... (see .github/workflows/test-e2e.yml for full CI pipeline). For doctests: go test ./doctests or invoke via .github/workflows/doctests.yaml.

• commands.go: Central command registry and interface definitions; all command implementations are wired here
• command.go: Command struct definition and core command execution logic that underpins all Redis operations
• dial_retry_backoff.go: Implements automatic retry logic with exponential backoff for resilient connection handling
• command_policy_resolver.go: Routes commands to appropriate Redis nodes in Cluster and Sentinel topologies
• auth/auth.go: Handles Redis ACL authentication and credential management
• acl_commands.go: Implements ACL (access control list) commands; patterns used here repeat across bitmap_commands.go and cluster_commands.go
• .github/workflows/test-e2e.yml: CI pipeline defining how the client is tested against live Redis instances; reference for test expectations
• async_handoff_integration_test.go: Integration test demonstrating async command queueing patterns; important for understanding non-blocking usage

Start here: (1) new Redis commands: add to acl_commands.go (or bitmap_commands.go / cluster_commands.go if category-specific), implement in commands.go, test in corresponding _test.go file. (2) connection/retry logic: modify dial_retry_backoff.go or adapters.go. (3) authentication: extend auth/auth.go or auth/reauth_credentials_listener.go. (4) cluster/routing: edit command_policy_resolver.go. All changes require paired tests; see existing *_test.go files as templates.

1. RESP protocol version: code supports RESP3 but still handles RESP2; ensure Redis protocol version expectations match (see command_test.go). 2. Redis version compatibility: README states support for Redis 8.0+, but tests may fail with Redis 7.2 or Stack 7.2; validate server version before deployment. 3. Connection pool tuning: no explicit pool size configuration visible in root files; check adapters.go for defaults and tune for your workload. 4. Docker compose for testing: .github/workflows/test-e2e.yml relies on redis service; local docker-compose.yml required for integration tests or tests will hang/fail. 5. Module imports: some tests use internal command recorders (command_recorder_test.go); ensure test tags like -tags=integration are used correctly.

• RESP Protocol (Redis Serialization Protocol) — go-redis communicates with Redis servers using RESP/RESP3; understanding the wire format is essential for debugging protocol issues, tracing command flow in command.go, and understanding adapters.go connection handling.
• Connection Pooling with Exponential Backoff Retry — dial_retry_backoff.go implements resilient connection handling; a key pattern for production stability that junior engineers must understand to tune reliability and prevent connection exhaustion.
• Redis Cluster Slot Mapping & Command Routing — command_policy_resolver.go routes commands to cluster nodes based on CRC16 slot hashing; essential for understanding how go-redis scales to multi-node Redis deployments and why cluster topology changes require re-slotting.
• Redis Sentinel (High Availability) — The codebase handles Sentinel topology discovery (hints in command_policy_resolver.go and auth/reauth_credentials_listener.go); critical for HA deployments where failover is automatic but client topology awareness must be maintained.
• ACL (Access Control Lists) & Credential Refresh — auth/reauth_credentials_listener.go handles runtime ACL updates without reconnection; understanding this pattern is important for secure multi-tenant deployments and credential rotation.
• Async Command Handoff / Pipelining — async_handoff_integration_test.go demonstrates non-blocking command queueing; a performance optimization pattern essential for high-throughput scenarios where batching multiple commands reduces round-trip latency.
• CRC16 Hash Slot Calculation — go-redis uses CRC16 (via cespare/xxhash) to map keys to cluster slots in command_policy_resolver.go; understanding the deterministic hash ensures correct key distribution and is critical when debugging cluster migration issues.

• redis/redis — The Redis server itself; go-redis is the official client for this, so understanding Redis command semantics and recent changes (8.0, 8.2, 8.4) directly informs client development.
• go-redis/cache — Companion library that provides a caching layer abstraction built on top of go-redis/v9 for common cache patterns.
• google/redigo — Predecessor/alternative Redis Go client (less actively maintained); useful historical reference for command wrapping patterns and architectural decisions.
• redis-sentinel/sentinel — Redis Sentinel documentation and reference; go-redis's command_policy_resolver.go implements Sentinel topology awareness, so understanding Sentinel is critical for cluster/HA features.
• redis/redis-hashes — Official Redis command reference and specification; referenced in tests and needed to validate command implementations in acl_commands.go, bitmap_commands.go, etc.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive integration tests for Redis Cluster MGET edge cases

The repo has a cluster_commands.go file and an example at example/cluster-mget/, but there's no dedicated test file for cluster-specific MGET behavior (e.g., handling key distribution across slots, partial failures, reshuffling). The existing async_handoff_integration_test.go suggests async patterns are tested, but cluster MGET edge cases warrant dedicated coverage to prevent regressions in multi-slot scenarios.

• [ ] Create cluster_mget_integration_test.go in the root directory
• [ ] Add tests for MGET with keys spanning multiple cluster slots
• [ ] Add tests for MGET behavior during cluster reshuffling/slot migration
• [ ] Add tests for partial failures (some nodes down, others responding) during cluster MGET
• [ ] Reference and verify against cluster_commands.go implementation
• [ ] Run against docker-compose.yml Redis cluster setup

Implement missing command digest tests for all command categories

The repo has command_digest_test.go which tests command routing/hashing, but based on file structure there are separate command files (acl_commands.go, bitmap_commands.go, cluster_commands.go, commands.go). Each category likely has unique digest requirements for cluster routing. Comprehensive digest tests ensure commands are correctly hashed to cluster slots.

• [ ] Review command_digest_test.go for existing coverage patterns
• [ ] Add digest tests for ACL commands (from acl_commands.go) - test command variants like SETUSER
• [ ] Add digest tests for bitmap commands (from bitmap_commands.go) - test BITOP with multiple keys
• [ ] Add digest tests for cluster-specific commands (from cluster_commands.go) - test slot computation
• [ ] Verify tests cover both single-key and multi-key command variants
• [ ] Update tests to validate cluster slot consistency

Add doctest examples for auth and credential lifecycle

The repo has comprehensive doctests in the doctests/ directory covering features like Bloom filters, geospatial, hashes, etc., but there's no auth_tutorial_test.go or similar covering the auth package (auth/auth.go, auth/reauth_credentials_listener.go). Given Redis ACL/RBAC is critical for production, documented examples with runnable code would be valuable.

• [ ] Create doctests/auth_tutorial_test.go with runnable examples
• [ ] Add doctest example for basic AUTH with username/password
• [ ] Add doctest example for ACL-based authentication (Redis 6.0+)
• [ ] Add doctest example demonstrating ReauthCredentialsListener for credential rotation
• [ ] Add doctest example showing context cancellation during auth
• [ ] Ensure examples work against the docker-compose.yml setup with proper ACL configuration
• [ ] Add corresponding example to README.md auth section if missing

• Add missing unit tests for error cases in command_digest_test.go and command_policy_resolver.go; currently sparse coverage for edge cases like invalid cluster slots or malformed policy responses.
• Improve docstring coverage for exported functions in adapters.go and async command handoff pattern (async_handoff_integration_test.go shows the feature but lacks API documentation in main commands.go).
• Implement a missing integration test for Redis 8.4-specific command changes mentioned in README (some commands changed between 8.0 and 8.4); audit acl_commands.go and bitmap_commands.go for version-specific behavior and add version guards.

The redis/go-redis codebase demonstrates reasonable security practices overall. No critical vulnerabilities were identified in the provided dependency file (go.mod shows only standard, well-maintained dependencies). However, the Docker/test configuration exhibits several medium and low-severity security concerns, primarily around relaxed TLS authentication, enabled debug/module commands, and exposed ports. These are acceptable for development and testing environments but should be hardened for production use. The codebase itself appears to follow good practices with no evident hardcoded credentials, injection vulnerabilities, or dependency security issues in the analyzed files. Recommendations focus on strengthening Docker configurations and ensuring stricter security settings in non-test deployments.

• Medium · Insecure Docker Container Configuration - TLS Client Authentication Set to Optional — docker-compose.yml - redis service command. The docker-compose.yml configures Redis with '--tls-auth-clients optional', which allows clients to connect without presenting valid TLS certificates. This weakens mutual TLS authentication and could allow unauthorized clients to establish connections if TLS is not strictly enforced at the application level. Fix: Change '--tls-auth-clients optional' to '--tls-auth-clients yes' to enforce mandatory client certificate authentication. This ensures all clients must present valid TLS certificates.
• Medium · Exposed Debug Command in Docker Configuration — docker-compose.yml - redis service command. The docker-compose.yml enables the DEBUG command with '--enable-debug-command yes', which provides internal Redis diagnostics and monitoring capabilities. This could expose sensitive information about Redis internals if this configuration is used in non-test environments. Fix: Remove '--enable-debug-command yes' from production configurations. If debug commands are needed, restrict them to development/test environments only and ensure proper access controls are in place.
• Medium · Module Command Enabled in Docker Configuration — docker-compose.yml - redis service command. The docker-compose.yml enables module commands with '--enable-module-command yes'. This allows loading and unloading of Redis modules at runtime, which could be exploited if access controls are not properly configured. Fix: Disable '--enable-module-command yes' unless modules are explicitly required. If modules must be loaded, enforce strict access controls via ACLs and limit who can execute module commands.
• Low · Missing Persistence Configuration in Docker — docker-compose.yml - redis service command. The docker-compose.yml uses '--save ""' which disables RDB persistence entirely. While this may be intentional for testing, it means no data durability in case of crashes unless explicitly configured at the application level. Fix: For production use, configure appropriate persistence strategy using '--save' with proper snapshot intervals or use AOF (Append-Only File) persistence to ensure data durability.
• Low · Exposed Redis Ports in Docker Configuration — docker-compose.yml - redis service ports configuration. The docker-compose.yml exposes Redis ports 6379 (standard) and 6666 (TLS) directly on the host machine without network restrictions. In a development environment this is acceptable, but in production this could expose Redis to unauthorized access. Fix: In production environments, restrict port exposure using firewall rules or bind Redis to specific interfaces only. Consider using network isolation and VPNs for remote access.
• Low · Cluster Ports Exposed Without Restrictions — docker-compose.yml - osscluster service ports configuration. The docker-compose.yml exposes cluster ports 16600-16605 without apparent access restrictions, which could allow unauthorized nodes to attempt to join the cluster. Fix: Implement network-level access controls to restrict cluster port access to authorized cluster members only. Use firewall rules to limit access to these ports.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.