Skip to content

fix(auth): support Redis Cloud secret env var alias#913

Merged
joshrotenberg merged 1 commit into
mainfrom
fix-cloud-secret-env-var-consistency
Mar 20, 2026
Merged

fix(auth): support Redis Cloud secret env var alias#913
joshrotenberg merged 1 commit into
mainfrom
fix-cloud-secret-env-var-consistency

Conversation

@joshrotenberg
Copy link
Copy Markdown
Collaborator

Summary

  • standardize on REDIS_CLOUD_SECRET_KEY as the canonical Redis Cloud secret env var
  • keep REDIS_CLOUD_API_SECRET working as a compatibility alias in CLI, core config resolution, and MCP OAuth env handling
  • add regression tests for alias lookup and update the docs that still presented the alias as primary

Testing

  • cargo test -p redisctl-core
  • cargo test -p redisctl-mcp
  • cargo test -p redisctl
  • cargo clippy --all-targets --all-features -- -D warnings

Closes #908

@joshrotenberg joshrotenberg merged commit fd55ef6 into main Mar 20, 2026
22 checks passed
@joshrotenberg joshrotenberg deleted the fix-cloud-secret-env-var-consistency branch March 20, 2026 17:29
joshrotenberg added a commit that referenced this pull request May 28, 2026
Both `cloud_secret_env_prefers_canonical_name` and
`cloud_secret_env_falls_back_to_alias` (added in #913) mutate the same
process-wide env vars (`REDIS_CLOUD_SECRET_KEY` and
`REDIS_CLOUD_API_SECRET`). cargo test runs in parallel by default, so
when one test sets `REDIS_CLOUD_SECRET_KEY=canonical-secret` and the
other expects that key to be unset, whichever wins the race gets the
wrong env state and fails.

Observed symptom on PR #924's CI:

    state::tests::cloud_secret_env_falls_back_to_alias
      left:  "canonical-secret"
      right: "alias-secret"

Reproduced locally on `main` — the failing test alternates between the
two depending on scheduling. Five consecutive runs with the fix all
pass; serial-only runs already passed.

Fix: annotate both tests with `#[serial_test::serial(cloud_secret_env)]`
to put them in the same named serialization group. `serial_test` is
already a workspace dev-dep used by `redisctl-core/src/config/config.rs`
for the same reason; this just adds it to `redisctl-mcp`'s dev-deps
and applies the standard pattern.

Test plan
- cargo fmt --all -- --check
- cargo test -p redisctl-mcp --features cloud --lib state::tests::cloud_secret
  (run 5x in a loop; all green)
joshrotenberg added a commit that referenced this pull request May 28, 2026
Both `cloud_secret_env_prefers_canonical_name` and
`cloud_secret_env_falls_back_to_alias` (added in #913) mutate the same
process-wide env vars (`REDIS_CLOUD_SECRET_KEY` and
`REDIS_CLOUD_API_SECRET`). cargo test runs in parallel by default, so
when one test sets `REDIS_CLOUD_SECRET_KEY=canonical-secret` and the
other expects that key to be unset, whichever wins the race gets the
wrong env state and fails.

Observed symptom on PR #924's CI:

    state::tests::cloud_secret_env_falls_back_to_alias
      left:  "canonical-secret"
      right: "alias-secret"

Reproduced locally on `main` — the failing test alternates between the
two depending on scheduling. Five consecutive runs with the fix all
pass; serial-only runs already passed.

Fix: annotate both tests with `#[serial_test::serial(cloud_secret_env)]`
to put them in the same named serialization group. `serial_test` is
already a workspace dev-dep used by `redisctl-core/src/config/config.rs`
for the same reason; this just adds it to `redisctl-mcp`'s dev-deps
and applies the standard pattern.

Test plan
- cargo fmt --all -- --check
- cargo test -p redisctl-mcp --features cloud --lib state::tests::cloud_secret
  (run 5x in a loop; all green)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

fix(auth): unify Redis Cloud secret env var name across CLI, core, MCP, and docs

1 participant