Add operation name attribute on gateway.plan spans #2807
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
🦋 Changeset detectedLatest commit: 70ecdb1 The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
trevor-scheer
suggested changes
Oct 5, 2023
gateway-js/src/__tests__/gateway/__snapshots__/opentelemetry.test.ts.snap
Outdated
Show resolved
Hide resolved
|
When making changes like this in the gateway, is the expectation we should also attempt to make a similar change (as close as possible) in router to maintain observability parity? |
trevor-scheer
approved these changes
Oct 20, 2023
trevor-scheer
force-pushed
the
operationNameOnGatewayPlanSpanNext
branch
from
34099bd to
59f1e2d
Compare
|
@theJC generally speaking, yes. I should have a better answer for you next week in this particular case. |
|
Changeset added. prettier code format issue with my updates to the tests fixed as well. |
trevor-scheer
approved these changes
Oct 23, 2023
|
@theJC in this particular case, we don't intend to maintain parity with the router. The router team is currently working on a more robust solution to configuring otel. |
pull bot
pushed a commit
to NOUIY/federation
that referenced
this pull request
Nov 28, 2023
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to next, this PR will be updated. # Releases ## @apollo/composition@2.6.0 ### Minor Changes - Update `license` field in `package.json` to use `Elastic-2.0` SPDX identifier ([apollographql#2741](apollographql#2741)) - Introduce the new `@policy` scope for composition ([apollographql#2818](apollographql#2818)) > Note that this directive will only be _fully_ supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that _composition_ of valid `@policy` directive applications will succeed, but the resulting supergraph will not be _executable_ by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement. Users may now compose `@policy` applications from their subgraphs into a supergraph. The directive is defined as follows: ```graphql scalar federation__Policy directive @Policy(policies: [[federation__Policy!]!]!) on | FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM ``` The `Policy` scalar is effectively a `String`, similar to the `FieldSet` type. In order to compose your `@policy` usages, you must update your subgraph's federation spec version to v2.6 and add the `@policy` import to your existing imports like so: ```graphql @link(url: "https://specs.apollo.dev/federation/v2.6", import: [..., "@Policy"]) ``` ### Patch Changes - Updated dependencies \[[`b18841be`](apollographql@b18841b), [`e325b499`](apollographql@e325b49)]: - @apollo/query-graphs@2.6.0 - @apollo/federation-internals@2.6.0 ## @apollo/gateway@2.6.0 ### Minor Changes - Add more information to OpenTelemetry spans. ([apollographql#2700](apollographql#2700)) Rename `operationName` to `graphql.operation.name` and add a `graphql.operation.type` attribute, in conformance with the OpenTelemetry Semantic Conventions for GraphQL. The `operationName` attribute is now deprecated, but it is still emitted alongside `graphql.operation.name`. Add a `graphql.document` span attribute to the `gateway.request` span, containing the entire GraphQL source sent in the request. This feature is disable by default. When one or more GraphQL or internal errors occur, report them in the OpenTelemetry span in which they took place, as an exception event. This feature is disabled by default. To enable the `graphql.document` span attribute and the exception event reporting, add the following entries to your `ApolloGateway` instance configuration: ```ts const gateway = new ApolloGateway({ // ... telemetry: { // Set to `true` to include the `graphql.document` attribute includeDocument: true, // Set to `true` to report all exception events, or set to a number // to report at most that number of exception events per span reportExceptions: true, // or: reportExceptions: 1 }, }); ``` - Update `license` field in `package.json` to use `Elastic-2.0` SPDX identifier ([apollographql#2741](apollographql#2741)) - Introduce the new `@policy` scope for composition ([apollographql#2818](apollographql#2818)) > Note that this directive will only be _fully_ supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that _composition_ of valid `@policy` directive applications will succeed, but the resulting supergraph will not be _executable_ by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement. Users may now compose `@policy` applications from their subgraphs into a supergraph. The directive is defined as follows: ```graphql scalar federation__Policy directive @Policy(policies: [[federation__Policy!]!]!) on | FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM ``` The `Policy` scalar is effectively a `String`, similar to the `FieldSet` type. In order to compose your `@policy` usages, you must update your subgraph's federation spec version to v2.6 and add the `@policy` import to your existing imports like so: ```graphql @link(url: "https://specs.apollo.dev/federation/v2.6", import: [..., "@Policy"]) ``` - Add graphql.operation.name attribute on gateway.plan span ([apollographql#2807](apollographql#2807)) ### Patch Changes - Updated dependencies \[[`b18841be`](apollographql@b18841b), [`e325b499`](apollographql@e325b49)]: - @apollo/query-planner@2.6.0 - @apollo/composition@2.6.0 - @apollo/federation-internals@2.6.0 ## @apollo/federation-internals@2.6.0 ### Minor Changes - Update `license` field in `package.json` to use `Elastic-2.0` SPDX identifier ([apollographql#2741](apollographql#2741)) - Introduce the new `@policy` scope for composition ([apollographql#2818](apollographql#2818)) > Note that this directive will only be _fully_ supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that _composition_ of valid `@policy` directive applications will succeed, but the resulting supergraph will not be _executable_ by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement. Users may now compose `@policy` applications from their subgraphs into a supergraph. The directive is defined as follows: ```graphql scalar federation__Policy directive @Policy(policies: [[federation__Policy!]!]!) on | FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM ``` The `Policy` scalar is effectively a `String`, similar to the `FieldSet` type. In order to compose your `@policy` usages, you must update your subgraph's federation spec version to v2.6 and add the `@policy` import to your existing imports like so: ```graphql @link(url: "https://specs.apollo.dev/federation/v2.6", import: [..., "@Policy"]) ``` ## @apollo/query-graphs@2.6.0 ### Minor Changes - Update `license` field in `package.json` to use `Elastic-2.0` SPDX identifier ([apollographql#2741](apollographql#2741)) - Introduce the new `@policy` scope for composition ([apollographql#2818](apollographql#2818)) > Note that this directive will only be _fully_ supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that _composition_ of valid `@policy` directive applications will succeed, but the resulting supergraph will not be _executable_ by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement. Users may now compose `@policy` applications from their subgraphs into a supergraph. The directive is defined as follows: ```graphql scalar federation__Policy directive @Policy(policies: [[federation__Policy!]!]!) on | FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM ``` The `Policy` scalar is effectively a `String`, similar to the `FieldSet` type. In order to compose your `@policy` usages, you must update your subgraph's federation spec version to v2.6 and add the `@policy` import to your existing imports like so: ```graphql @link(url: "https://specs.apollo.dev/federation/v2.6", import: [..., "@Policy"]) ``` ### Patch Changes - Updated dependencies \[[`b18841be`](apollographql@b18841b), [`e325b499`](apollographql@e325b49)]: - @apollo/federation-internals@2.6.0 ## @apollo/query-planner@2.6.0 ### Minor Changes - Update `license` field in `package.json` to use `Elastic-2.0` SPDX identifier ([apollographql#2741](apollographql#2741)) - Introduce the new `@policy` scope for composition ([apollographql#2818](apollographql#2818)) > Note that this directive will only be _fully_ supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that _composition_ of valid `@policy` directive applications will succeed, but the resulting supergraph will not be _executable_ by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement. Users may now compose `@policy` applications from their subgraphs into a supergraph. The directive is defined as follows: ```graphql scalar federation__Policy directive @Policy(policies: [[federation__Policy!]!]!) on | FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM ``` The `Policy` scalar is effectively a `String`, similar to the `FieldSet` type. In order to compose your `@policy` usages, you must update your subgraph's federation spec version to v2.6 and add the `@policy` import to your existing imports like so: ```graphql @link(url: "https://specs.apollo.dev/federation/v2.6", import: [..., "@Policy"]) ``` ### Patch Changes - Updated dependencies \[[`b18841be`](apollographql@b18841b), [`e325b499`](apollographql@e325b49)]: - @apollo/query-graphs@2.6.0 - @apollo/federation-internals@2.6.0 ## @apollo/subgraph@2.6.0 ### Patch Changes - Updated dependencies \[[`b18841be`](apollographql@b18841b), [`e325b499`](apollographql@e325b49)]: - @apollo/federation-internals@2.6.0 ## apollo-federation-integration-testsuite@2.6.0 ### Minor Changes - Update `license` field in `package.json` to use `Elastic-2.0` SPDX identifier ([apollographql#2741](apollographql#2741)) - Introduce the new `@policy` scope for composition ([apollographql#2818](apollographql#2818)) > Note that this directive will only be _fully_ supported by the Apollo Router as a GraphOS Enterprise feature at runtime. Also note that _composition_ of valid `@policy` directive applications will succeed, but the resulting supergraph will not be _executable_ by the Gateway or an Apollo Router which doesn't have the GraphOS Enterprise entitlement. Users may now compose `@policy` applications from their subgraphs into a supergraph. The directive is defined as follows: ```graphql scalar federation__Policy directive @Policy(policies: [[federation__Policy!]!]!) on | FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM ``` The `Policy` scalar is effectively a `String`, similar to the `FieldSet` type. In order to compose your `@policy` usages, you must update your subgraph's federation spec version to v2.6 and add the `@policy` import to your existing imports like so: ```graphql @link(url: "https://specs.apollo.dev/federation/v2.6", import: [..., "@Policy"]) ``` Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addresses #2802
Add operation name to gateway.plan span