[Bug]: Global Redis password defaults do not work for every documented workload kind

Open Beginner friendly
#1,160 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

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

Research direction

Open docs/platform/enterprise-platform/deployment.mdx at the “Global Redis/Valkey defaults” section and review the linked platform issue for the fixed operator version and acceptance criteria. Add a clearly scoped warning covering authenticated Redis behavior for VirtualMCPServer, MCPServer, and MCPRemoteProxy, while noting that passwordless Redis is unaffected. Done means the documented configuration no longer recommends a setup that crash-loops two workload kinds.

Written by the indexing model from the issue text.

Description

bug documentation needs-triage

Page or section

https://docs.stacklok.com/platform/enterprise-platform/deployment#global-redisvalkey-defaults

Source: docs/platform/enterprise-platform/deployment.mdx, "Global Redis/Valkey defaults".

What's wrong?

The page says global.redis.host, existingSecret, and existingSecretKey provide default session storage for MCPServer, MCPRemoteProxy, and VirtualMCPServer workloads with no explicit spec.sessionStorage.

That is only fully true for VirtualMCPServer when Redis requires authentication.

The operator forwards the default address to all three workload kinds, but its MCPServer and MCPRemoteProxy deployment builders do not fall back to the global/default Redis Secret. Those child pods get the address without THV_SESSION_REDIS_PASSWORD and fail with:

failed to create Redis session storage: redis: failed to connect: NOAUTH Authentication required

An explicit per-resource spec.sessionStorage.passwordRef works for all three resource kinds.

The current documentation therefore recommends a configuration that renders successfully but crash-loops two of the three documented consumers.

Suggested fix

Until the platform pins an operator release containing the fix, add a clearly scoped warning:

  • authenticated global/default Redis works as documented for VirtualMCPServer;
  • MCPServer and MCPRemoteProxy must set an explicit Redis spec.sessionStorage with passwordRef;
  • passwordless Redis is unaffected by the missing password injection.

Remove the warning when the fixed version is released and update the compatibility statement if the correction is version-specific.

Additional context

Platform bug with source analysis and acceptance criteria:

https://github.com/stacklok/stacklok-enterprise-platform/issues/4310

This was reproduced with Stacklok Enterprise Platform v0.17.0 and remains present in the ToolHive source vendored on current platform main as of 4ac27745a.

Dominant language
TypeScript
Stars
4
Forks
3
Avg merge
1d 7h
Merged PRs (30d)
41

Contributor guide

Open the contributing guide

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 stacklok/docs-website

All issues in stacklok/docs-website

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.