Cloning a resolver evaluates its arguments' thunks #231
Comments
|
If you use Try to modify your code to this schemaComposer.createResolver({
- type: () => userTypeComposer.getResolver('createOne').getType(),
+ type: () => userTypeComposer.getResolver('createOne').type,
args: {
- record: () => userTypeComposer.getResolver('createOne').getArgType('record')
+ record: () => userTypeComposer.getResolver('createOne').getArg('record').type
}
// ...
})When you call |
|
Hi, thanks for your answer. I changed .getType/.getArgType occurrences everywhere but it doesn't seem to help. The crash happens sooner in the thunk, when it tries to read the |
|
This is my current workaround, I use this function instead of function cloneResolverIssue231(resolver: compose.Resolver, opts?: Partial<compose.ResolverDefinition<unknown, Context>>) {
const oldOpts: compose.ResolverDefinition<unknown, Context> = {};
for (const key in resolver) {
if (resolver.hasOwnProperty(key)) {
// @ts-ignore
oldOpts[key] = resolver[key];
}
}
// Delete args property, or Resolver ctor calls setArgs, that crashes
delete oldOpts.args;
const clonedResolver = new compose.Resolver({ ...oldOpts, ...opts }, resolver.schemaComposer);
clonedResolver.args = resolver.args;
return clonedResolver;
}Right now it seems there a no undesirable side effects. The key is to avoid |
|
I don't like workarounds ))) It will be cool if you open PR with a broken test like these https://github.com/graphql-compose/graphql-compose/tree/master/src/__tests__/github_issues Tnx! |
…eDefinition> stability in complex schemas and provide stronger & better DX Closes graphql-compose#231
|
@toverux please check a new version of If any other errors occur, please let me know. Thanks. |
|
🎉 This issue has been resolved in version 7.12.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
Thanks @nodkz, I'll try it out the next time I run an upgrade pass on our app, if there's a problem I'll let you know. |
I have a cyclic dependency between two TypeComposers. Usually, this kind of scenario does not cause any problem when using thunks for resolvers types and resolvers' arguments' types, like this:
However, I have a middleware system (very much inspired by the one from this library), and that system makes use of
Resolver.clone()to wrap the original resolver and expose a derived resolver with a wrapper resolve function.Here is how it looks:
The
allWithMiddlewaresfunction eventually makes a call to thewithMiddlewaresfunction, that is very similar to graphql-compose'sResolver.withMiddlewares()method:Now I get this stack trace:
Decoding it, we can see that there's this cyclic dependency:
user => domain => user.Here is the code that actually crashes (see the line with a comment):
Interestingly, this happens because
Resolver.clone()is used inwithMiddlewares(). For some reason, the cloning function calls a lot of other functions, and eventually it ends up in the TypeMapper, where the thunk is evaluated.Not cloning the resolver and just changing its resolve function works.
I'd consider this as bug and an undesired side effect, as I should be able to clone a Resolver object without evaluating its thunked configuration (ie. just make a copy of the object).
I'd guess the library's
Resolver.withMiddlewares()method has the same problem since it does basically the same thing.Now, I'd understand if that's too complicated to fix, and I know how to workaround this, but I'd really like to still be able to clone my resolvers to apply middlewares on top of them.
I hope I am clear enough. Cyclic dependencies are always a source of fun.
As always - thanks a lot for your library.
The text was updated successfully, but these errors were encountered: