@graphql-tools/delegate

Patch Changes

• #2600 e5ea5f4 Thanks @enisdenjo! - Drop prototype polluting keys from subgraph results before merging them

  Response keys named __proto__, constructor or prototype, which a client can produce with a field alias, were only filtered at the top level of a merged result. Nested occurrences were passed to mergeDeep, which walks the prototype chain and could end up writing to Object.prototype or Function.prototype.

  Such keys are now removed at every depth of a subgraph result before it takes part in a merge, and projectDataSelectionSet no longer treats an inherited property as an already projected field.

• Updated dependencies [8cbdfd0]:

  • @graphql-tools/batch-execute@10.1.0

@graphql-tools/delegate@12.1.3

@graphql-tools/delegate@12.1.2

Patch Changes

• #2498 9ff0daf Thanks @enisdenjo! - Fix delegated argument serialization when fields are filtered or renamed

  Inline enum values now remain enum literals, and original variable definitions are preserved while still referenced by fragments, selections, directives, or other arguments.

Minor Changes

• #2473 6f2c3b6 Thanks @enisdenjo! - Automatically resolve plain merged-type references returned by local stitching resolvers

  Local fields introduced through typeDefs or resolvers are wrapped by stitchSchemas. When they return a partial merged type containing a usable key, stitching performs one initial delegation with type merging enabled. The existing stitching planner then handles computed fields, @requires dependencies, batching, nested entities, and fields owned by other subschemas.

Patch Changes

• #2473 6f2c3b6 Thanks @enisdenjo! - defaultMergedResolver now falls back to the literal field name when an external object does not have the requested response key

  Plain resolver data merged into an external object is keyed by field name, so an aliased request used to resolve to null even though the value was there:

  {
    person {
      fullName: name
    }
  }
  

  // merged object carries resolver data by field name
  { id: '1', name: 'Local' }
  

  Previously fullName was null because only the alias was looked up. Now it resolves to 'Local' by field name, matching plain graphql-js behavior. When the response key is present (e.g. the field came from a subschema), it is still preferred.

Patch Changes

• #2474 8a08de3 Thanks @enisdenjo! - Fix delegated argument variable type compatibility

  Avoid reusing variables whose types are incompatible with target schema argument types, and create correctly typed variables instead.

• #2475 65ce370 Thanks @enisdenjo! - Fix enum argument serialization when delegating to a field removed from the transformed schema.

  When a delegated query field is filtered from the transformed schema, its arguments now use the original subschema for type lookup. This ensures enum values are sent as typed variables instead of invalid quoted enum literals while preserving input field transforms for fields that remain exposed.

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.

Patch Changes

• Updated dependencies [4311d79]:
  • @graphql-tools/batch-execute@10.0.9