July 13, 2026

@graphql-tools/batch-delegate@10.0.26

Patch Changes

• Updated dependencies [0bbdbbc]:
  • @graphql-tools/delegate@12.0.19

@graphql-tools/delegate@12.0.19

Patch Changes

• #2351 0bbdbbc Thanks @ardatan! - Fix @provides so the gateway only requests the provided fields the client actually selected, and stops delegating to the owner subgraph when @provides already covers the request.

  Previously, when a subgraph declared @provides(fields: "...") on a field, the gateway would still:

  1. Forward every field listed in @provides to that subgraph, even when the client never asked for them.
  2. After receiving the response, plan additional delegations to the owner subgraph for @provides-covered fields whenever the providing subgraph declared them as @external, even though the data was already returned.

  For example with:

  # subgraph B (provider)
  type Query {
    entity: Entity @provides(fields: "name description")
  }
  
  type Entity @key(fields: "id") {
    id: ID!
    name: String! @external
    description: String! @external
  }

  a client query of { entity { id name } } would still cause the gateway to ask subgraph B for description and fetch name again from subgraph A (the owner of Entity).

  After this fix:

  • Only the @provides fields the client actually selected are forwarded to the providing subgraph (request side).
  • The delegation planner now recognises @provides declarations at every nested level (e.g. @provides(fields: "nested { nestedNested { name description } }")) and @provides declarations made via inline fragments on union/interface members (e.g. @provides(fields: "... on Book { title }")), so the gateway no longer round-trips to the owner subgraph for fields that the providing subgraph has already returned.
  • Fragment spreads in the client query are correctly handled when selecting nested @provides-covered fields. Previously, using a fragment spread (e.g. ...MyFrag) for nested @external fields could cause an unnecessary delegation to the owner because selection subtraction compared only the spread name with the explicit @provides fields. The planner now resolves fragment spreads before subtracting provided selections, while preserving the fragment type condition and directives when only part of a fragment remains.

  Aliases, direct field selections, fragments, fragment spreads, @include/@skip directives wrapping a @provides field, and nested @provides selections are preserved without unnecessary owner delegations.

@graphql-tools/federation@4.4.8

Patch Changes

• #2351 0bbdbbc Thanks @ardatan! - Fix @provides so the gateway only requests the provided fields the client actually selected, and stops delegating to the owner subgraph when @provides already covers the request.

  Previously, when a subgraph declared @provides(fields: "...") on a field, the gateway would still:

  1. Forward every field listed in @provides to that subgraph, even when the client never asked for them.
  2. After receiving the response, plan additional delegations to the owner subgraph for @provides-covered fields whenever the providing subgraph declared them as @external, even though the data was already returned.

  For example with:

  # subgraph B (provider)
  type Query {
    entity: Entity @provides(fields: "name description")
  }
  
  type Entity @key(fields: "id") {
    id: ID!
    name: String! @external
    description: String! @external
  }

  a client query of { entity { id name } } would still cause the gateway to ask subgraph B for description and fetch name again from subgraph A (the owner of Entity).

  After this fix:

  • Only the @provides fields the client actually selected are forwarded to the providing subgraph (request side).
  • The delegation planner now recognises @provides declarations at every nested level (e.g. @provides(fields: "nested { nestedNested { name description } }")) and @provides declarations made via inline fragments on union/interface members (e.g. @provides(fields: "... on Book { title }")), so the gateway no longer round-trips to the owner subgraph for fields that the providing subgraph has already returned.
  • Fragment spreads in the client query are correctly handled when selecting nested @provides-covered fields. Previously, using a fragment spread (e.g. ...MyFrag) for nested @external fields could cause an unnecessary delegation to the owner because selection subtraction compared only the spread name with the explicit @provides fields. The planner now resolves fragment spreads before subtracting provided selections, while preserving the fragment type condition and directives when only part of a fragment remains.

  Aliases, direct field selections, fragments, fragment spreads, @include/@skip directives wrapping a @provides field, and nested @provides selections are preserved without unnecessary owner delegations.

• Updated dependencies [0bbdbbc]:

  • @graphql-tools/delegate@12.0.19
  • @graphql-tools/stitch@10.1.24
  • @graphql-tools/wrap@11.1.18

@graphql-mesh/fusion-runtime@1.10.10

Patch Changes

• Updated dependencies [0bbdbbc]:
  • @graphql-tools/delegate@12.0.19
  • @graphql-tools/stitch@10.1.24
  • @graphql-tools/federation@4.4.8
  • @graphql-tools/stitching-directives@4.0.24
  • @graphql-tools/wrap@11.1.18

@graphql-hive/gateway@2.10.4

Patch Changes

• Updated dependencies []:
  • @graphql-hive/gateway-runtime@2.9.10
  • @graphql-hive/plugin-aws-sigv4@2.0.53
  • @graphql-hive/plugin-opentelemetry@1.4.35
  • @graphql-mesh/plugin-prometheus@2.1.51

@graphql-hive/nestjs@2.0.84

Patch Changes

• Updated dependencies []:
  • @graphql-hive/gateway@2.10.4

@graphql-hive/plugin-aws-sigv4@2.0.53

Patch Changes

• Updated dependencies []:
  • @graphql-mesh/fusion-runtime@1.10.10

@graphql-hive/plugin-opentelemetry@1.4.35

Patch Changes

• Updated dependencies []:
  • @graphql-hive/gateway-runtime@2.9.10

@graphql-mesh/plugin-prometheus@2.1.51

Patch Changes

• Updated dependencies []:
  • @graphql-hive/gateway-runtime@2.9.10

@graphql-hive/router-runtime@1.4.15

Patch Changes

• #2467 d51423d Thanks @vyacheslav-voloshyn! - Fix BatchFetch execution dropping the $representations variable for an entity alias that resolved to zero representations.

  When a BatchFetch plan node groups several entity fetches for the same subgraph into one aliased _entities request and one alias resolves to an empty representation list (e.g. a nullable federated field that is null), buildBatchFetchVariables omitted that alias's variable. The batched document still declares it as a required [_Any!]!, so the operation declared a variable it never provided and the subgraph rejected the whole request — failing the sibling aliases that did have representations.

  Empty aliases now send [], keeping the operation valid (_entities(representations: []) simply returns []).

• Updated dependencies [0bbdbbc]:

  • @graphql-tools/delegate@12.0.19
  • @graphql-tools/federation@4.4.8
  • @graphql-mesh/fusion-runtime@1.10.10

@graphql-hive/gateway-runtime@2.9.10

Patch Changes

• Updated dependencies [0bbdbbc]:
  • @graphql-tools/delegate@12.0.19
  • @graphql-tools/stitch@10.1.24
  • @graphql-tools/federation@4.4.8
  • @graphql-mesh/fusion-runtime@1.10.10
  • @graphql-tools/batch-delegate@10.0.26
  • @graphql-tools/wrap@11.1.18

@graphql-tools/stitch@10.1.24

Patch Changes

• #2351 0bbdbbc Thanks @ardatan! - Fix @provides so the gateway only requests the provided fields the client actually selected, and stops delegating to the owner subgraph when @provides already covers the request.

  Previously, when a subgraph declared @provides(fields: "...") on a field, the gateway would still:

  1. Forward every field listed in @provides to that subgraph, even when the client never asked for them.
  2. After receiving the response, plan additional delegations to the owner subgraph for @provides-covered fields whenever the providing subgraph declared them as @external, even though the data was already returned.

  For example with:

  # subgraph B (provider)
  type Query {
    entity: Entity @provides(fields: "name description")
  }
  
  type Entity @key(fields: "id") {
    id: ID!
    name: String! @external
    description: String! @external
  }

  a client query of { entity { id name } } would still cause the gateway to ask subgraph B for description and fetch name again from subgraph A (the owner of Entity).

  After this fix:

  • Only the @provides fields the client actually selected are forwarded to the providing subgraph (request side).
  • The delegation planner now recognises @provides declarations at every nested level (e.g. @provides(fields: "nested { nestedNested { name description } }")) and @provides declarations made via inline fragments on union/interface members (e.g. @provides(fields: "... on Book { title }")), so the gateway no longer round-trips to the owner subgraph for fields that the providing subgraph has already returned.
  • Fragment spreads in the client query are correctly handled when selecting nested @provides-covered fields. Previously, using a fragment spread (e.g. ...MyFrag) for nested @external fields could cause an unnecessary delegation to the owner because selection subtraction compared only the spread name with the explicit @provides fields. The planner now resolves fragment spreads before subtracting provided selections, while preserving the fragment type condition and directives when only part of a fragment remains.

  Aliases, direct field selections, fragments, fragment spreads, @include/@skip directives wrapping a @provides field, and nested @provides selections are preserved without unnecessary owner delegations.

• Updated dependencies [0bbdbbc]:

  • @graphql-tools/delegate@12.0.19
  • @graphql-tools/batch-delegate@10.0.26
  • @graphql-tools/wrap@11.1.18

@graphql-tools/stitching-directives@4.0.24

Patch Changes

• Updated dependencies [0bbdbbc]:
  • @graphql-tools/delegate@12.0.19

@graphql-hive/gateway-testing@8.0.10

Patch Changes

• Updated dependencies []:
  • @graphql-hive/gateway-runtime@2.9.10

@graphql-tools/wrap@11.1.18

Patch Changes

• Updated dependencies [0bbdbbc]:
  • @graphql-tools/delegate@12.0.19