There is no unique identifier in the library that allows you to truly track execution of a query
I realised this when putting together the PR for #270 together.
There are 2 stages to query execution (parse/validate then execute)
There is no common object passed between them.
graphql.execution.Execution builds a graphql.execution.ExecutionContext which is probably our best bet but its done AFTER the parse/validate
Also graphql.schema.DataFetchingEnvironment is not given this execution context and if there was a unique identifier in it would not be available to DataFetchers
I propose that the GraphQL library generate a UUID (and take one for people using other request identifiers such as Zipkin spans)
This would be passed down through graphql.execution.ExecutionContext / graphql.schema.DataFetchingEnvironment etc.. so code can "track / known" what theya re doding work for
For example a multi threaded query executor service could log / instrument better in terms of the UUID.
There is no unique identifier in the library that allows you to truly track execution of a query
I realised this when putting together the PR for #270 together.
There are 2 stages to query execution (parse/validate then execute)
There is no common object passed between them.
graphql.execution.Executionbuilds agraphql.execution.ExecutionContextwhich is probably our best bet but its done AFTER the parse/validateAlso
graphql.schema.DataFetchingEnvironmentis not given this execution context and if there was a unique identifier in it would not be available to DataFetchersI propose that the GraphQL library generate a UUID (and take one for people using other request identifiers such as Zipkin spans)
This would be passed down through
graphql.execution.ExecutionContext/graphql.schema.DataFetchingEnvironmentetc.. so code can "track / known" what theya re doding work forFor example a multi threaded query executor service could log / instrument better in terms of the UUID.