-
Notifications
You must be signed in to change notification settings - Fork 238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Query caching broken with some custom scalars and JIT #997
Comments
Thanks for reporting! Can you provide steps to reproduce? We often need a reproducible example, e.g. some code that allows someone else to recreate your problem by just copying and pasting it. If it involves more than a couple of different file, create a new repository on GitHub and add a link to that. |
Okay, I've created a repoduction repo here: https://github.com/lsanwick/custom-scalar-caching-example It appears that the issue appears with this configuration: await fastify.register(mercurius, {
schema,
resolvers,
jit: true,
graphiql: true,
}); If you disable JIT, or disable caching while keeping JIT enabled, I don't see the issue. jit: true,
cache: false, |
@mcollina Is that sufficient to work off of, or do you need anything else? |
I currently do not have much time to look into it. This looks like an issue inside graphql-jit. I never experience this exact issue so maybe there is something that intersects between that and luxon. |
I'm building a schema that has a number of custom scalars like
DateTime
that are automatically validated and parsed into a LuxonDateTime
object when provided as arguments.This works great, except it seems to interact poorly with the default request cache, where subsequent requests will just provide the string representation of the argument.
Here's a toy implementation that shows the issue:
Example query
First response (correct)
Second response (incorrect)
Disabling the caching with
cache: false
on mercurius when registering the plugin fixes the issue.The text was updated successfully, but these errors were encountered: