Cannot use query complexity limitations on graphql cursor connections, cause it's not a list

[jrouaix]

Expected Behavior

Tried to use query complexity limitations on a field returning paginated nodes using cursor connections :

https://async-graphql.github.io/async-graphql/en/depth_and_complexity.html#limiting-query-complexity
https://async-graphql.github.io/async-graphql/en/cursor_connections.html

IMHO, we should be able to limit here based on some first, last parameters.

Actual Behavior

the complexity computation ComplexityType::Fn is ignored in the complexity visitor here :

async-graphql/src/validation/visitors/complexity.rs

Line 64 in a278cc1

if MetaTypeName::create(&meta_field.ty).is_list() {

Because the result type of the query is of type async_graphql::Result<Connection<usize, SomeOtherType, EmptyFields, EmptyFields>>

Steps to Reproduce the Problem

use some #[graphql(complexity = "... some_function_call() ... * child_complexity")]
https://async-graphql.github.io/async-graphql/en/depth_and_complexity.html#limiting-query-complexity
https://async-graphql.github.io/async-graphql/en/cursor_connections.html

both at the same time on a field.

the complexity will be ignored.

[jrouaix]

If I remove the condition, the expected behavior happens.
Perhaps it's a quick fix ?
Is this condition really an expected limitation ?

[jrouaix]

Hello ? @sunli829 ?
Any idea about this one ?
Would you prefer a PR ?

[jrouaix]

Anyone here with some thoughts about this ?
I strongly thinks it's a bug, and an easy one to kill, but no-one cares ?

[sunli829]

I'm so sorry to see this just now, I'll check tomorrow to see if this condition is really necessary. 🙂

[sunli829]

I was probably confused at the time. 😂

[jrouaix]

Thank you @sunli829 !