Start Query

The query context that we provide as payload with the event is the full query context on which the query middleware operates. This enables us to pick and choose the information that we want.

Stop Query

The stop event is raised once the query engine has completed processing the request. This event is even called if an error has occurred. Additional to the IQueryContext the event also provides the IExecutionResult.

Parser Events

The parser events are raised when the parser middleware is invoked. It is important to know that the Hot Chocolate server caches queries. This means that only the first time a query is executed, we can measure the parsing time.

Start Parsing

Stop Parsing

The stop event is raised once the parser finished. It is important to know that the stop event is even raised if a SyntaxException is thrown. The Document property on the IQueryContext will be null in this case. The parser middleware will add a property to the context data indicating if the query was retrieved from the cache: DocumentRetrievedFromCache.

Parsing Errors

The parser will throw a SyntaxException if the query is not syntactically correct. The SyntaxException will cause a query error.

Validation Events

The validation events are raised whenever the validation middleware is invoked. Like with the parsing middleware the validation middleware will cache validation results. This means that only the first validation of a query document can be used to measure the validation duration. The context property DocumentRetrievedFromCache can also be used in this case to detect if the validation result was pulled from the internal cache or if it was computed.

Validation Start

The validation start event is called once the validation middleware is invoked.

Resolver Start

The resolver start event is raised for each invocation of a resolver pipeline. The resolver pipeline is made-up of multiple field middleware components. The exact composition of such a pipeline varies on your setup.

Resolver Stop

The resolver stop event is raised once the execution of the resolver pipeline is completed. The provided result is the not completed result of the resolver. This means that the actual result that is integrated into the query result can differ since type converter and serialization are applied during field value completion.

There are two ways to register the diagnostics observer with the execution engine. You can either register the observer with the executor directly through the QueryExecutionBuilder or you can add the diagnostic observer to your dependency injection provider.

Registering the observer with the QueryExecutionBuilder does not require any dependency injection provider, but let`s you only inject infrastructure services.

If you want to use the observer in conjunction with your dependency injection provider you can also add the observer to your services. We have added an extension method for IServiceCollection that mirrors the builder extension.

services.AddDiagnosticObserver<MyDiagnosticObserver>();

If you are registering the diagnostics observer with the dependency injection you have to ensure that the resulting service provider is registered with the schema.

If you are using our AddGraphQL or AddStitchedSchema extensions, you should be covered. In the case that you are putting everything together yourself you will need to register the service provider with your schema manually.