Skip to content

fix(response_cache): don't require redis when disabled and require it when enabled#8684

Merged
bnjjj merged 4 commits intodevfrom
bnjjj/router_1538
Nov 28, 2025
Merged

fix(response_cache): don't require redis when disabled and require it when enabled#8684
bnjjj merged 4 commits intodevfrom
bnjjj/router_1538

Conversation

@bnjjj
Copy link
Copy Markdown
Contributor

@bnjjj bnjjj commented Nov 27, 2025

Previously, the router would attempt to connect to Redis for response caching regardless of whether response caching was enabled or disabled. This could cause unnecessary connection attempts and configuration errors even when the feature was explicitly disabled.

Now, the router properly validates Redis configuration based on the response cache state:

When response caching is disabled: Redis configuration is not required and no connection attempts are made.

When response caching is enabled: Redis configuration is validated and required. If a subgraph has caching enabled but no Redis configuration, the router will return a clear error:

Error: you must have a redis configured either for all subgraphs or for subgraph "products"

This validation ensures that:

  • You can disable response caching without needing to provide Redis configuration
  • When response caching is enabled, all enabled subgraphs have proper Redis connectivity (either via global all configuration or per-subgraph configuration)
  • Configuration errors are caught at startup with clear error messages

Example configuration that now works correctly:

response_cache:
  enabled: false  # Redis not required when disabled
  #
  subgraph:
    all:
      #
      enabled: false
response_cache:
  enabled: true
  #
  subgraph:
    all:
      enabled: true
      #
      redis:  
        urls:
          - redis://127.0.0.1:6379  # Required when enabled

Checklist

Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.

  • PR description explains the motivation for the change and relevant context for reviewing
  • PR description links appropriate GitHub/Jira tickets (creating when necessary)
  • Changeset is included for user-facing changes
  • Changes are compatible1
  • Documentation2 completed
  • Performance impact assessed and acceptable
  • Metrics and logs are added3 and documented
  • Tests added and passing4
    • Unit tests
    • Integration tests
    • Manual tests, as necessary

Exceptions

Note any exceptions here

Notes

Footnotes

  1. It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this.

  2. Configuration is an important part of many changes. Where applicable please try to document configuration examples.

  3. A lot of (if not most) features benefit from built-in observability and debug-level logs. Please read this guidance on metrics best-practices.

  4. Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions.

… when enabled

Signed-off-by: Benjamin <5719034+bnjjj@users.noreply.github.com>
@bnjjj bnjjj requested a review from a team November 27, 2025 15:14
@apollo-librarian
Copy link
Copy Markdown
Contributor

apollo-librarian bot commented Nov 27, 2025

✅ Docs preview has no changes

The preview was not built because there were no changes.

Build ID: bafad3508253ac36673cb999
Build Logs: View logs

@github-actions

This comment has been minimized.

Signed-off-by: Benjamin <5719034+bnjjj@users.noreply.github.com>
@bnjjj bnjjj requested a review from a team as a code owner November 27, 2025 15:16
@bnjjj bnjjj requested a review from Copilot November 27, 2025 15:16
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes the response cache plugin to properly validate Redis configuration based on whether caching is enabled or disabled, preventing unnecessary Redis connection attempts and configuration errors when the feature is explicitly disabled.

Key changes:

  • Added conditional Redis connection logic that only requires and connects to Redis when caching is enabled
  • Introduced validation that returns clear errors when caching is enabled but Redis configuration is missing
  • Added comprehensive test coverage for various enabled/disabled configuration combinations

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File Description
apollo-router/src/plugins/response_cache/plugin.rs Added conditional logic to check plugin and subgraph enabled state before connecting to Redis, added validation to ensure Redis config exists when needed, refactored subgraph_enabled into static method, and added comprehensive tests for various configuration scenarios
apollo-router/src/plugins/response_cache/tests.rs Refactored tests to use new create_subgraph_conf helper function and updated for_test signature to accept SubgraphConfiguration instead of raw HashMap
.changesets/fix_response_cache_redis_requirement.md Added changeset documentation explaining the behavior change with examples and validation rules

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread .changesets/fix_response_cache_redis_requirement.md Outdated
Comment thread .changesets/fix_response_cache_redis_requirement.md Outdated
Co-authored-by: Renée <renee.kooi@apollographql.com>
@bnjjj bnjjj merged commit a96d8bb into dev Nov 28, 2025
15 checks passed
@bnjjj bnjjj deleted the bnjjj/router_1538 branch November 28, 2025 08:36
@abernix abernix mentioned this pull request Dec 12, 2025
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.

4 participants