Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Feature]: Document Valkey support for the Redis-backed features

Open Beginner friendly
#6,425 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@dannyward630 is already working on this.

Since Oct 22, 2026.

  • #6464 by @dannyward630 — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
82/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Tech stack
markdown, redis
Domain
documentation

Research direction

Read guides/14-ragfs-cache.md and the relevant Redis-backed sections in guides/01-configuration.md, then find their Chinese counterparts under docs/zh. Update the three feature sections to document Valkey 7.2–9.1 using the existing Redis configuration, and show valkey-server as a RAGFS Quick Start alternative. Done when both language directories describe all three supported features consistently.

Written by the indexing model from the issue text.

Description

enhancement kernel
Issue Origin

Observed or reproduced in a real environment

Problem Statement

Valkey is an open source fork of Redis, maintained under the Linux Foundation and licensed under BSD-3-Clause. It was forked just before Redis moved to source-available licenses. It keeps the Redis protocol and commands, and existing Redis clients work with it unchanged. Many cloud providers offer it as a managed service, including Amazon ElastiCache, Google Cloud Memorystore, Tencent Cloud, and DigitalOcean.

OpenViking has three optional features that use a Redis server:

Feature Configuration Docs
RAGFS cache (CacheFS, QueueFS, PathLock, multi-write backups) cache.provider: "redis" guides/14-ragfs-cache.md
Account store cache account_store.provider: "redis_mysql" guides/01-configuration.md
Distributed session expiry idle_backend: "redis" guides/01-configuration.md

The docs for these features only mention Redis. A team that runs Valkey, or a managed service built on it, can't tell whether OpenViking supports it. Today they have to run their own validation, or deploy a separate Redis server just for OpenViking.

Proposed Solution

Document Valkey as a supported server for these three features. All three already work with Valkey through the existing redis configuration, so this is a docs-only change with no code or configuration changes.

  • Add a note to each feature's section that Valkey 7.2 to 9.1 is supported, with the same configuration as Redis.
  • In the RAGFS Quick Start, show valkey-server as an alternative to redis-server.
  • Update docs/en and docs/zh.

I would send this as three small PRs, one per feature. I'd need to use machine translation for the docs/zh changes, assuming that's preferable to excluding them, as I only speak English.

Alternatives Considered
  • A separate valkey provider name. OpenViking's clients never check which server they're connected to, so this would only add a second name for identical behavior.
  • Leave it undocumented. Valkey users would keep validating it themselves before relying on it.
Feature Area

Documentation

Use Case

A team that already runs Valkey for caching or queues can use the same deployment for OpenViking's Redis-backed features.

Example API (Optional)
{
  "cache": {
    "provider": "redis",
    "params": {
      "mode": "standalone",
      "endpoints": ["redis://valkey.example.com:6379"]
    }
  }
}
Additional Context

I tested at 0a2578e against Valkey 7.2.14, 8.0.11, 8.1.10, 9.0.6, and 9.1.2. These are the newest patch releases of every maintained Valkey line. I used Redis 8.10.2 as a control.

I tested each of the features as follows:

  • RAGFS cache: the existing cargo test -p ragfs --features cache suite, plus the Quick Start and multi-write backups through a running openviking-server.
  • Account store: the existing redis_mysql live test, plus a probe built through the server configuration.
  • Session expiry: two openviking-server instances with idle_backend: "redis". Idle sessions were committed exactly once, including after one instance was killed and the other took over.

Each feature ran on multiple topologies where supported. This included standalone, cluster, and Sentinel modes. The runs also covered ACL users and TLS. I ran every check against Redis 8.10.2 as well, and Valkey gave the same result in every case.

Area contacts from CONTRIBUTING.md: @baojun-zhang for Storage (RAGFS cache) and @qin-ctx for Platform (account store, session expiry).

Contribution
  • I am willing to contribute to implementing this feature
Dominant language
Python
Stars
40.2k
Forks
3.2k
Avg merge
1d 5h
Merged PRs (30d)
382

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from volcengine/OpenViking

All issues in volcengine/OpenViking

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.