Replies: 1 comment 1 reply
-
Yes, I noticed this too last week. I have to check why it has been done this way, because in the past, the cache was calculated only if cache is enabled for the request. I have to dig a little more to understand the reason for this change. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
In the source code of
@graphql-yoga/plugin-response-cache
, the user definedenabled(request)
is invoked after user defined fnbuildResponseCacheKey
which is confusing. Let's say for example this is an introspection query or it should be skipped based on headers, then that seems to be established. However, then suddenly you are surprised by the fact that you still have to deal with the fact thatbuildResponseCacheKey
is invoked to build a cache key anyway, even though it was already "determined" it was disabled since it was an introspection query / skipped request!This is very confusing for me and our users, it seems like you want to check
enabled(request)
first and THEN invokebuildResponseCacheKey
because why would you want to build a cache key for something that should not be cached anyway?@EmrysMyrddin
Beta Was this translation helpful? Give feedback.
All reactions