Extends GraphQL Spans #562
Conversation
| brief: "The number of errors that occurred during the operation." | ||
| type: int | ||
| examples: 3 | ||
| # TODO should we have something like outcome (success, failure) |
There was a problem hiding this comment.
I was not sure if we should have a property that signals if the execution was a success or a failure.
Then we would have to specify aswell what a 'success' and what a 'failure' is.
As a operation can fail completely ('data' is null) or partially (there are errors)
| type: int | ||
| examples: 3 | ||
| # TODO should we have something like outcome (success, failure) | ||
| # TODO how do we specify errors? |
There was a problem hiding this comment.
A GraphQL Operation can have multiple errors in the response:
{
"data": null,
"errors": [
{
"message": "Cannot return null for non-nullable field User",
"locations": [
{
"line": 3,
"column": 5
}
],
"path": [
"createUser",
"user"
],
"extensions": {
"code": "USERNAME_INVALID",
"message": "username is invalid"
}
}
]
}What is the best way to represent this in OpenTelemetry?
| examples: 3 | ||
| # TODO should we have something like outcome (success, failure) | ||
| # TODO how do we specify errors? | ||
| # TODO Should we ref network.transport, network.type, server.address etc? |
There was a problem hiding this comment.
This would have to be done with caution though. as graphql is protocol agonstic
| # TODO should we have something like outcome (success, failure) | ||
| # TODO how do we specify errors? | ||
| # TODO Should we ref network.transport, network.type, server.address etc? | ||
| # TODO There are more spans like validation, parsing, variable coercion and response formatting. Should we add them as separate span types? |
There was a problem hiding this comment.
It provides a lot of value to know how long a specific operation is spending validating, parsing or formatting.
Should we add specific spans for this?
| @@ -1,6 +1,6 @@ | |||
| groups: | |||
| - id: graphql | |||
| prefix: graphql | |||
| - id: graphql.server.request | |||
There was a problem hiding this comment.
This are just the graphql.server spans. Should we also specific the graphql.client spans?
| - id: selection.field.isDeprecated | ||
| brief: "Whether the field that is beeing resolved is deprecated." | ||
| type: bool | ||
| examples: true |
There was a problem hiding this comment.
What do we do with validation errors? If someone sends a invalid GraphQL requests that e.g. could not be parsed. Which span should be emitted
| - id: selection.field.isDeprecated | ||
| brief: "Whether the field that is beeing resolved is deprecated." | ||
| type: bool | ||
| examples: true |
There was a problem hiding this comment.
Another thing that is not yet specified are the subscriptions.
A subscription is a long running operation that returns an event stream. Similar to websockets/signalR etc.
Is there prior art in open telemetry how this could be handled?
A subscription starts with a "Subscribe" call that returns a event stream. Each event in this event stream is mapped to a graphql result. This means that, the subscribe call and the execution of each event, give different insights. These insights are more important than a arbitrary long root spans that spans the whole graphql execution.
Co-authored-by: Tobias Tengler <[email protected]>
Co-authored-by: Tobias Tengler <[email protected]>
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
|
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
|
@jsuereth Can this Pull Request be reopened? How can i get feedback for this? |
Fixes #
Changes
This pull requests extends the capabilities of graphql open telemetry.
It adds a span for the execution of a GraphQL operation and a span for the resolvers.
I left a few comments in the definition to open a dicussion about the changes.
Merge requirement checklist