Directive on query element is not resolving arguments

Is there an existing issue for this?

• I have searched the existing issues

Product

Hot Chocolate

Describe the bug

I created a directive @urlContext(url: String!) for the Query element. Added a middleware and was set that for the .Use on the directive definition. When the middleware is executed the directive is found below the context.Directive but when executing context.Directive.GetArgument<string>("url") I always getting null out.

If instead adding the directive on the field/field definition the middleware and get arguments methods are working as expected.

Workaround that I found is to use this to find the directive argument value

var directive = context.Operation.Definition.Directives.FirstOrDefault(x => x.Name.Value == context.Directive.Name);
var argument = directive?.Arguments.FirstOrDefault(x => x.Name.Value == "url");
var urlString = argument?.Value.Value as string;

if ((argument?.Value.Kind != HotChocolate.Language.SyntaxKind.Variable
    || context.Variables.TryGetVariable(urlString, out urlString))
    && !string.IsNullOrEmpty(urlString)
    && Uri.TryCreate(urlString, UriKind.RelativeOrAbsolute, out var url))
{

}

Steps to reproduce

Schema

directive @UrlContext(
  """
  The url for the contextual information.
  """
  url: String = "not-set"
) on QUERY | MUTATION | FIELD | OBJECT | FIELD_DEFINITION

type Query {
  content: String!
}

Query

query @UrlContext(url: "https://github.com")  {
  content
}

Directive definition

public class UrlContext
{
    public string Url { get; set; }
}

public class UrlContextType : DirectiveType<UrlContext>
{
    protected override void Configure(IDirectiveTypeDescriptor<UrlContext> descriptor)
    {
        descriptor.Argument(x => x.Url)
            //.Type<NonNullType<StringType>>()
            .Description("The url for the contextual information.")
            .DefaultValue("not-set");

        descriptor.Location(DirectiveLocation.Query | DirectiveLocation.Mutation | DirectiveLocation.Field | DirectiveLocation.FieldDefinition | DirectiveLocation.Object);

        descriptor.Use<UrlContextMiddleware>();
    }
}

Directive middleware

public class UrlContextMiddleware
{
    private readonly FieldDelegate _next;

    public UrlContextMiddleware(
        FieldDelegate next)
    {
        _next = next;
    }

    // this method must be called InvokeAsync or Invoke
    public async ValueTask InvokeAsync(IDirectiveContext context)
    {
        // Code up here is executed before the following middleware
        // and the actual field resolver
        var url = context.Directive.GetArgument<string>("url"); // this always return null when directive is on query

        // This invokes the next middleware
        // or if we are at the last middleware the field resolver
        await _next(context);

        // Code down here is executed after all later middleware
        // and the actual field resolver has finished executing
    }
}

Relevant log output

No response

Additional Context?

No response

Version

13.0.0-preview.85

[michaelstaib]

I would use headers for thinks that belong into headers. What I would be carefull with is allowing people to put contextual information on selections. The GraphQL query would become very crowded. Also, its not very clear where you have to set them.

If you set them just on the operation level it would be fine.

[Tasteful]

I have fixed the link … if you want to try again.

Thanks, now it was working.

I know that we can pass the information as http-headers and I want to avoid that as-well because looking to use GQL Federation for extensibility and I think it will be harder (if at all possible) to get that information down to the sub-graphs if needed.

Header propagation is an well-known concept with federated graphs.

Do you, from the above information, think that it’s better to send this contextual information as http-header information?

So you can access the directives on each field … we do not coerce them by default because it has a performance impact. You could do that in the query compilation phase but there are variables that could be passed into the arguments … these would prevent you from doing it there.

the query compilation phase is that the same as implementing an IHttpRequestInterceptor or how do I inject my own code inside that?