Closed DonnyVerduijn closed 2 weeks ago
Would you like to create a PR for this issue?
https://github.com/DonnyVerduijn/nestjs-cqrs-starter Should be straightforward to reproduce.
Would you like to create a PR that addresses this issue?
I'll try to take a look at this today.
👀
:eyes:
Hey, minimal reproduction is not installed graphql-query-complexity. So complexity is not working, but expected behavior. I created minimal example repository. It doesn't use federation, but will be work too.
@kamilmysliwiec I tested complexity with federated graph. Complexity extension works fine. testing repo: https://github.com/choco14t/example-gateway-logging/tree/check-complexity
Set default complexity 1 per field, user.posts complexity 5. Return complexity 11 when executed query below.
query QueryPosts {
posts {
id
title
user {
id
posts { # set complexity: 5
id
}
}
}
}
I'm submitting a...
Current behavior
Currently, when using federated graphs, the complexity option property does not limit the allowed query depth, when there is a circular reference between two object types (when fields are added by resolvers that are decorated with the ResolveField decorator).
Expected behavior
The complexity configuration options property should work with federated graphs and resolvers that are decorated with the ResolveField decorator, when they recursively resolve through circular references between two object types. The complexity of queries still need to be limited on a per resolver basis.
Minimal reproduction of the problem with instructions
https://github.com/hardyscc/nestjs-cqrs-starter ./apps/service-account/src/account/resolver/user.resolver.ts
This still allows the accounts field to be resolved from the user field inside an account type.
What is the motivation / use case for changing the behavior?
Circular referencing can pose security risks that can be exploited by malicious queries
Environment