fix(response caching): respect interface objects as entities by aaronArinder · Pull Request #8582 · apollographql/router

aaronArinder · 2025-11-10T20:48:12Z

for cache invalidation keys, we only supported objects and not interface entities

Checklist

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

Exceptions

Note any exceptions here

Notes

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. ↩

apollo-librarian · 2025-11-10T20:48:39Z

✅ Docs preview ready

The preview is ready to be viewed. View the preview

File Changes

0 new, 10 changed, 0 removed

* graphos/routing/(latest)/customization/custom-binary.mdx
* graphos/routing/(latest)/observability/graphos/graphos-reporting.mdx
* graphos/routing/(latest)/observability/router-telemetry-otel/telemetry-pipelines/metrics-exporters/otlp.mdx
* graphos/routing/(latest)/observability/router-telemetry-otel/telemetry-pipelines/trace-exporters/otlp.mdx
* graphos/routing/(latest)/observability/router-telemetry-otel/telemetry-pipelines/trace-exporters/overview.mdx
* graphos/routing/(latest)/operations/apq.mdx
* graphos/routing/(latest)/performance/caching/response-caching/faq.mdx
* graphos/routing/(latest)/performance/caching/response-caching/observability.mdx
* graphos/routing/(latest)/performance/caching/response-caching/quickstart.mdx
* graphos/routing/(latest)/security/authorization.mdx

Build ID: 4ea92bf93ba65e6e189352a9
Build Logs: View logs

URL: https://www.apollographql.com/docs/deploy-preview/4ea92bf93ba65e6e189352a9

bnjjj · 2025-11-12T09:42:36Z

-                    }
-                })
-        });
+    // supports both Object types and Interface types (for interface objects with isInterfaceObject: true)


Where do you check that isInterfaceObject is set to true ? Do you assume it's checked at composition ?

I'm assuming in composition; the second test below, where we have a concrete object and a normal interface (ie, not an interface object) shows that (I think, at least insofar as I understand how parsing/validating works, which is very little), where the first test (with just an interface object and no concrete object) gets us back the __typename we'd expect (in that case, Item)

Cc @duckki I don't have enough knowledge on this maybe you could help me

Let me double check the status of validation rules.

Update: We allow @cacheTag on interface objects in composition. But, I need to check how it's represented in supergraph schemas. Unfortunately, I'm away from office today. I'll think more about this when I have a chance.

I reviewed the supergraph composition of cache-tag directives applied on interface object entity types.

In supergraph, those directives are translated using @directive directive applied on the interface type, instead of its implementation types.

Since we don't normally allow @cacheTag on interface, such directive applications only happen with interface object in specified subgraphs.

Thus, in order to check if a type has @cacheTag, we must

Check the type (interface or object) has one or more @cacheTag directives applied on it.

(For object types) check all of its interface types if one or more @cacheTag directives applied on them.

I thought @cacheTag is per graph? so in a graph that there is an @interfaceObject we won't have any of its implementations - hence why do we need to look up the interface types?

edit: nvm, found it -> filtering per graph is done afterwards

Co-authored-by: Renée <renee.kooi@apollographql.com>

duckki

It looked good.
I pushed a commit handling another case.

Cache tags can be on an interface object or regular objects. Also, we should consider the combinations of the source subgraph and the target subgraph when we jump from one to another.

From non-interface object to non-interface object: Originally handled
From interface object to interface object: Handled in the previous commit of this PR
From non-interface object to interface object:Handled in my new commit pushed to this PR
From interface object to non-interface object: Not handled (= No cache keys since it can't be determined)

I also added two more tests demonstrating those cases.

duckki · 2025-11-14T03:01:42Z

-                    }
-                })
-        });
+    // supports both Object types and Interface types (for interface objects with isInterfaceObject: true)


I reviewed the supergraph composition of cache-tag directives applied on interface object entity types.

In supergraph, those directives are translated using @directive directive applied on the interface type, instead of its implementation types.

Since we don't normally allow @cacheTag on interface, such directive applications only happen with interface object in specified subgraphs.

Thus, in order to check if a type has @cacheTag, we must

Check the type (interface or object) has one or more @cacheTag directives applied on it.

(For object types) check all of its interface types if one or more @cacheTag directives applied on them.

duckki · 2025-11-17T17:58:26Z

Over the weekend, I realized it could be improved:

From non-interface object to interface object:Handled in my new commit pushed to this PR
- We don't need to enumerate what interfaces the given object type implements, since we should already know the interface-object type from the query plan. I'll fix this.
From interface object to non-interface object: Not handled (= No cache keys since it can't be determined)
- Since we validated all implementation types have the same set of cache tags, we can retrieve that from any object type implements the interface. Thus, we can handle this case. I'll fix this, too.

duckki · 2025-11-19T02:43:15Z

My attempt to improve it didn't really work. Let me explain:

From non-interface object to interface object:Handled in my new commit pushed to this PR

We don't need to enumerate what interfaces the given object type implements, since we should already know the interface-object type from the query plan. I'll fix this.

I wanted to derive the interface type name from the query plan, but it's not readily available (we would have to parse the fetch query to get that). However, I think the situation is not too bad. Even if we enumerate all interfaces, the result will be at most one anyways. That's because we can't really have multiple interface objects covering the same object type.

Instead, I just moved the directive filtering before collecting them for efficiency.

From interface object to non-interface object: Not handled (= No cache keys since it can't be determined)

Since we validated all implementation types have the same set of cache tags, we can retrieve that from any object type implements the interface. Thus, we can handle this case. I'll fix this, too.

I misspoke. Actually, object types CAN have different sets of cache tags. So, in this case, we can't determine cache tag after all. 😢 This is a fundamental issue with interface objects.

I just added some more comments in the code explaining it.

I'll leave end-to-end testing to you. Otherwise, this PR looks good.

aaronArinder · 2025-11-19T15:28:53Z

ack on e2e testing, @duckki; I'll probably not get to it until next week, but have it on my list of todos

thank you so much for running with this pr and fleshing it out into something useable!

fix(response caching): respect interface entities

6bbf9ea

aaronArinder requested a review from a team November 10, 2025 20:48

This comment has been minimized.

Sign in to view

goto-bus-stop reviewed Nov 11, 2025

View reviewed changes

Comment thread apollo-router/src/plugins/response_cache/plugin.rs Outdated

goto-bus-stop mentioned this pull request Nov 11, 2025

fix(response_cache): include the actual type name in error for nonexistent type #8580

Closed

bnjjj reviewed Nov 12, 2025

View reviewed changes

Update apollo-router/src/plugins/response_cache/plugin.rs

e97bc74

Co-authored-by: Renée <renee.kooi@apollographql.com>

aaronArinder requested a review from bnjjj November 12, 2025 14:23

duckki approved these changes Nov 14, 2025

View reviewed changes

duckki force-pushed the aaron/response_caching_interface_object_resolution branch from ea07517 to a7b0d4a Compare November 14, 2025 06:39

Handle the subgraph jump from non-interface object to interface object

fa9d801

duckki force-pushed the aaron/response_caching_interface_object_resolution branch from a7b0d4a to fa9d801 Compare November 14, 2025 06:44

duckki added 2 commits November 18, 2025 18:00

Add more comments in get_invalidation_entity_keys_from_schema function

be79f8a

Filter directives early before collecting

568860a

changeset

63d93f4

aaronArinder requested a review from a team as a code owner November 25, 2025 19:21

aaronArinder merged commit 5957c84 into dev Nov 25, 2025
14 of 15 checks passed

aaronArinder deleted the aaron/response_caching_interface_object_resolution branch November 25, 2025 20:11

abernix mentioned this pull request Dec 12, 2025

prep release: v2.10.0 #8758

Merged

Conversation

aaronArinder commented Nov 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Footnotes

Uh oh!

This comment has been minimized.

apollo-librarian bot commented Nov 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Docs preview ready

Uh oh!

Uh oh!

bnjjj Nov 12, 2025

Choose a reason for hiding this comment

Uh oh!

aaronArinder Nov 12, 2025

Choose a reason for hiding this comment

Uh oh!

bnjjj Nov 12, 2025

Choose a reason for hiding this comment

Uh oh!

duckki Nov 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

duckki Nov 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dariuszkuc Nov 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

duckki left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

duckki Nov 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

duckki commented Nov 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

duckki commented Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aaronArinder commented Nov 19, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

aaronArinder commented Nov 10, 2025 •

edited

Loading

apollo-librarian bot commented Nov 10, 2025 •

edited

Loading

duckki Nov 12, 2025 •

edited

Loading

duckki Nov 14, 2025 •

edited

Loading

dariuszkuc Nov 14, 2025 •

edited

Loading

duckki left a comment •

edited

Loading

duckki Nov 14, 2025 •

edited

Loading

duckki commented Nov 17, 2025 •

edited

Loading

duckki commented Nov 19, 2025 •

edited

Loading