fix(response_cache): don't require redis when disabled and require it when enabled#8684
Merged
fix(response_cache): don't require redis when disabled and require it when enabled#8684
Conversation
… when enabled Signed-off-by: Benjamin <5719034+bnjjj@users.noreply.github.com>
Contributor
✅ Docs preview has no changesThe preview was not built because there were no changes. Build ID: bafad3508253ac36673cb999 |
This comment has been minimized.
This comment has been minimized.
Contributor
There was a problem hiding this comment.
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.
BrynCooke
approved these changes
Nov 27, 2025
Co-authored-by: Renée <renee.kooi@apollographql.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
This validation ensures that:
allconfiguration or per-subgraph configuration)Example configuration that now works correctly:
Checklist
Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.
Exceptions
Note any exceptions here
Notes
Footnotes
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. ↩
Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩
A lot of (if not most) features benefit from built-in observability and
debug-level logs. Please read this guidance on metrics best-practices. ↩Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩