Regarding is_default_resolver check

[nilansaha]

Can anyone confirm that this line is kind of a proxy check if it's a default resolver or not. To me it seems it just checks if there is a resolver set for that field. If not then we can assume it is a default resolver there obviously because that segment of the field is still being resolved and run. So why two separate checks one with the line and another with is_default_resolver(resolver). I feel that line should be part of the is_default_resolver function

[rafalp]

To me it seems it just checks if there is a resolver set for that field.

It checks if queried field has custom (user defined) resolver set on it. Please note that it runs not only is_default_resolver check but also the is_introspection_field check.

We trace only custom resolvers for performance reasons: many tracing calls can add up on larger result sets, and custom resolvers are ones most likely to matter for performance.

[nilansaha]

Gotcha. I agree with not tracing introspection_fields but sometimes non-custom resolver tracing is useful if you want to see which fields are being access by users for api lifecycle management and all. Very very useful during schema checks and deprecating things in prod. I have created a PR to allow to do that if someone wants. Does not break any current functionality but allows people to trace default fields if they want. Can you take a look ?

#608