Skip to content

Releases: apollographql/federation

@apollo/[email protected]

27 Sep 04:20
ad94371
Compare
Choose a tag to compare

Patch Changes

  • Fixes handling of a __typename selection during query planning process. (#3156)

    When expanding fragments we were keeping references to the same Fields regardless where those fragments appeared in our original selection set. This was generally fine as in most cases we would have same inline fragment selection sets across whole operation but was causing problems when we were applying another optimization by collapsing those expanded inline fragments creating a new selection set. As a result, if any single field selection (within that fragment) would perform optimization around the usage of __typename, ALL occurrences of that field selection would get that optimization as well.

  • Add validations for demand control directive applications (#3148)

@apollo/[email protected]

27 Sep 04:20
ad94371
Compare
Choose a tag to compare

@apollo/[email protected]

23 Sep 19:25
98285e5
Compare
Choose a tag to compare
Pre-release

CHANGELOG for @apollo/subgraph

2.9.1

Patch Changes

2.9.0

Patch Changes

2.8.5

Patch Changes

2.8.4

Patch Changes

2.8.3

Patch Changes

2.8.3-beta.2

Patch Changes

2.8.3-beta.1

Patch Changes

2.8.3-beta.0

Patch Changes

2.8.2

Patch Changes

2.8.1

Patch Changes

2.8.0

Patch Changes

2.8.0-alpha.1

Patch Changes

2.8.0-alpha.0

Patch Changes

2.7.8

Patch Changes

2.7.7

Patch Changes

2.7.6

Patch Changes

2.7.5

Patch Changes

2.7.4

Patch Changes

2.7.3

Patch Changes

2.7.2

Patch Changes

2.7.1

Patch Changes

2.7.0

Minor Changes

  • Implement progressive @override functionality (#2911)

    The progressive @override feature brings a new argument to the @override directive: label: String. When a label is added to an @override application, the override becomes conditional, depending on parameters provided to the query planner (a set of which labels should be overridden). Note that this feature will be supported in router for enterprise users only.

    Out-of-the-box, the router will support a percentage-based use case for progressive @override. For example:

    type Query {
      hello: String @override(from: "original", label: "percent(5)")
    }

    The above example will override the root hello field from the "original" subgraph 5% of the time.

    More complex use cases will be supported by the router via the use of coprocessors/rhai to resolve arbitrary labels to true/false values (i.e. via a feature flag service).

Patch Changes

2.6.3

Patch Changes

2.6.2

Patch Changes

2.6.1

Patch Changes

2.6.0

Patch Changes

2.5.7

Patch Changes

2.5.6

Patch Changes

2.5.5

Patch Changes

  • Fix specific case for requesting __typename on interface entity type (#2775)

    In certain cases, when resolving a __typename on an interface entity (due to it actual being requested in the operation), that fetch group could previously be trimmed / treated as useless. At a glance, it appears to be a redundant step, i.e.:

    { ... on Product { __typename id }} => { ... on Product { __typename} }
    

    It's actually necessary to preserve this in the case that we're coming from an interface object to an (entity) interface so that we can resolve the concrete __typename correctly.

  • Updated dependencies []:
    ...

Read more

@apollo/[email protected]

23 Sep 19:25
98285e5
Compare
Choose a tag to compare
Pre-release

CHANGELOG for @apollo/query-planner

2.9.1

Patch Changes

2.9.0

Patch Changes

2.8.5

🔒 Security

CVE-2024-43414: Prevent uncontrolled recursion for complex queries

Correct a bug where complex queries can cause uncontrolled recursion due to failure to reduce the number of possible query plans (classified as CWE-674). (#3128)

This weakness impacts all v2 versions of @apollo/query-planner prior to this release. See the associated Github Advisory, GHSA-fmj9-77q8-g6c4, for more information.

2.8.4

Patch Changes

2.8.3

Patch Changes

2.8.3-beta.2

Patch Changes

2.8.3-beta.1

Patch Changes

2.8.3-beta.0

Patch Changes

2.8.2

Patch Changes

2.8.1

Patch Changes

2.8.0

Minor Changes

  • Implement new directives to allow getting and setting context. This allows resolvers to reference and access data referenced by entities that exist in the GraphPath that was used to access the field. The following example demonstrates the ability to access the prop field within the Child resolver. (#2988)

    type Query {
      p: Parent!
    }
    type Parent @key(fields: "id") @context(name: "context") {
      id: ID!
      child: Child!
      prop: String!
    }
    type Child @key(fields: "id") {
      id: ID!
      b: String!
      field(a: String @fromContext(field: "$context { prop }")): Int!
    }

Patch Changes

2.8.0-alpha.1

Patch Changes

2.8.0-alpha.0

Minor Changes

  • Implement new directives to allow getting and setting context. This allows resolvers to reference and access data referenced by entities that exist in the GraphPath that was used to access the field. The following example demonstrates the ability to access the prop field within the Child resolver. (#2988)

    type Query {
      p: Parent!
    }
    type Parent @key(fields: "id") @context(name: "context") {
      id: ID!
      child: Child!
      prop: String!
    }
    type Child @key(fields: "id") {
      id: ID!
      b: String!
      field(a: String @fromContext(field: "$context { prop }")): Int!
    }

Patch Changes

2.7.8

Patch Changes

2.7.7

Patch Changes

2.7.6

Patch Changes

  • There is no functionality change between 2.7.5 and 2.7.6. Triggering new release as previous one released partially leading to a broken experience. (#2997)

  • Updated dependencies []:

2.7.5

Patch Changes

  • Fix issue with missing fragment definitions due to generateQueryFragments. (#2993)

    An incorrect implementation detail in generateQueryFragments caused certain queries to be missing fragment defi...

Read more

@apollo/[email protected]

23 Sep 19:25
98285e5
Compare
Choose a tag to compare
Pre-release

CHANGELOG for @apollo/query-graphs

2.9.1

Patch Changes

2.9.0

Patch Changes

2.8.5

Patch Changes

2.8.4

Patch Changes

2.8.3

Patch Changes

2.8.3-beta.2

Patch Changes

2.8.3-beta.1

Patch Changes

2.8.3-beta.0

Patch Changes

2.8.2

Patch Changes

2.8.1

Patch Changes

2.8.0

Minor Changes

  • Implement new directives to allow getting and setting context. This allows resolvers to reference and access data referenced by entities that exist in the GraphPath that was used to access the field. The following example demonstrates the ability to access the prop field within the Child resolver. (#2988)

    type Query {
      p: Parent!
    }
    type Parent @key(fields: "id") @context(name: "context") {
      id: ID!
      child: Child!
      prop: String!
    }
    type Child @key(fields: "id") {
      id: ID!
      b: String!
      field(a: String @fromContext(field: "$context { prop }")): Int!
    }

Patch Changes

2.8.0-alpha.1

Patch Changes

  • Fix bug in context-matching logic for interfaces-implementing-interfaces (#3014) (#3015)

    A field is considered to match a context if the field's parent type (in the original query) either has @context on it, or implements/is a member of a type with @context on it. We ended up missing the case where interfaces implement interfaces; this PR introduces a fix.

  • Updated dependencies []:

2.8.0-alpha.0

Minor Changes

  • Implement new directives to allow getting and setting context. This allows resolvers to reference and access data referenced by entities that exist in the GraphPath that was used to access the field. The following example demonstrates the ability to access the prop field within the Child resolver. (#2988)

    type Query {
      p: Parent!
    }
    type Parent @key(fields: "id") @context(name: "context") {
      id: ID!
      child: Child!
      prop: String!
    }
    type Child @key(fields: "id") {
      id: ID!
      b: String!
      field(a: String @fromContext(field: "$context { prop }")): Int!
    }

Patch Changes

2.7.8

Patch Changes

2.7.7

Patch Changes

2.7.6

Patch Changes

2.7.5

Patch Changes

2.7.4

Patch Changes

2.7.3

Patch Changes

2.7.2

Patch Changes

2.7.1

Patch Changes

2.7.0

Minor Changes

  • Implement progressive @override functionality (#2911)

    The progressive @override feature brings a new argument to the @override directive: label: String. When a label is added to an @override application, the override becomes conditional, depending on parameters provided to the query planner (a set of which labels should be overridden). Note that this feature will be supported in router for enterprise users only.

    Out-of-the-box, the router will support a percentage-based use case...

Read more

@apollo/[email protected]

23 Sep 19:25
98285e5
Compare
Choose a tag to compare
Pre-release

CHANGELOG for @apollo/gateway

2.9.1

Patch Changes

2.9.0

Patch Changes

2.8.5

🔒 Security

CVE-2024-43414: Prevent uncontrolled recursion for complex queries

Correct a bug where complex queries can cause uncontrolled recursion due to failure to reduce the number of possible query plans (classified as CWE-674). (#3128)

This weakness impacts all v2 versions of @apollo/gateway prior to this release. See the associated Github Advisory, GHSA-fmj9-77q8-g6c4, for more information.

2.8.4

Patch Changes

2.8.3

Patch Changes

2.8.3-beta.2

Patch Changes

2.8.3-beta.1

Patch Changes

2.8.3-beta.0

Patch Changes

2.8.2

Patch Changes

2.8.1

Patch Changes

2.8.0

Minor Changes

  • Implement new directives to allow getting and setting context. This allows resolvers to reference and access data referenced by entities that exist in the GraphPath that was used to access the field. The following example demonstrates the ability to access the prop field within the Child resolver. (#2988)

    type Query {
      p: Parent!
    }
    type Parent @key(fields: "id") @context(name: "context") {
      id: ID!
      child: Child!
      prop: String!
    }
    type Child @key(fields: "id") {
      id: ID!
      b: String!
      field(a: String @fromContext(field: "$context { prop }")): Int!
    }

Patch Changes

2.8.0-alpha.1

Patch Changes

2.8.0-alpha.0

Minor Changes

  • Implement new directives to allow getting and setting context. This allows resolvers to reference and access data referenced by entities that exist in the GraphPath that was used to access the field. The following example demonstrates the ability to access the prop field within the Child resolver. (#2988)

    type Query {
      p: Parent!
    }
    type Parent @key(fields: "id") @context(name: "context") {
      id: ID!
      child: Child!
      prop: String!
    }
    type Child @key(fields: "id") {
      id: ID!
      b: String!
      field(a: String @fromContext(field: "$context { prop }")): Int!
    }

Patch Changes

2.7.8

Patch Changes

  • Triggering a clean 2.7.8 release now that harmonizer build has been fixed. (#3010)

  • Updated dependencies [[`2ad72802044310a528e8944...

Read more

@apollo/[email protected]

23 Sep 19:25
98285e5
Compare
Choose a tag to compare
Pre-release

CHANGELOG for @apollo/federation-internals

2.9.1

Patch Changes

  • Fix edge cases for subgraph extraction logic when using spec renaming or specs URLs that look similar to specs.apollo.dev. (#3136)

  • Fix bugs in composition when merging nulls in directive applications and when handling renames. (#3134)

2.9.0

Minor Changes

  • Implements two new directives for defining custom costs for demand control. The @cost directive allows setting a custom weight to a particular field in the graph, overriding the default cost calculation. The @listSize directive gives the cost calculator information about how to estimate the size of lists returned by subgraphs. This can either be a static size or a value derived from input arguments, such as paging parameters. (#3074)

Patch Changes

  • Reduce memory overhead during satisfiability checking when there are many options. (#3109)

  • Fix issue where variable was not passed into subgraph when embedded in a fragment (#3119)

2.8.5

2.8.4

Patch Changes

  • When auto-upgrading schemas from fed1, never add @Shareable on subscription fields. (#3094)

  • Save time in SchemaUpgrader by pre-computing which subgraphs contain each type (#3057)

2.8.3

Patch Changes

  • dummy commit to force beta.2 (#3078)

  • For very large graphs cloning types with lots of join directives can be expensive. Since these directives will not be used in the Schema that is cloned for toAPISchema(), add the ability to optionally omit them (#3053)

  • Use sets instead of arrays for tracking schema type/directive referencers. (#3067)

2.8.3-beta.2

Patch Changes

  • dummy commit to force beta.2 (#3078)

2.8.3-beta.1

2.8.3-beta.0

Patch Changes

  • For very large graphs cloning types with lots of join directives can be expensive. Since these directives will not be used in the Schema that is cloned for toAPISchema(), add the ability to optionally omit them (#3053)

  • Use sets instead of arrays for tracking schema type/directive referencers. (#3067)

2.8.2

Patch Changes

  • generateQueryFragments() could generate fragments with naming collisions when nested (#3043)

2.8.1

2.8.0

Minor Changes

  • Implement new directives to allow getting and setting context. This allows resolvers to reference and access data referenced by entities that exist in the GraphPath that was used to access the field. The following example demonstrates the ability to access the prop field within the Child resolver. (#2988)

    type Query {
      p: Parent!
    }
    type Parent @key(fields: "id") @context(name: "context") {
      id: ID!
      child: Child!
      prop: String!
    }
    type Child @key(fields: "id") {
      id: ID!
      b: String!
      field(a: String @fromContext(field: "$context { prop }")): Int!
    }

Patch Changes

  • Various set context bugfixes (#3017)

2.8.0-alpha.1

2.8.0-alpha.0

Minor Changes

  • Implement new directives to allow getting and setting context. This allows resolvers to reference and access data referenced by entities that exist in the GraphPath that was used to access the field. The following example demonstrates the ability to access the prop field within the Child resolver. (#2988)

    type Query {
      p: Parent!
    }
    type Parent @key(fields: "id") @context(name: "context") {
      id: ID!
      child: Child!
      prop: String!
    }
    type Child @key(fields: "id") {
      id: ID!
      b: String!
      field(a: String @fromContext(field: "$context { prop }")): Int!
    }

2.7.8

Patch Changes

  • Triggering a clean 2.7.8 release now that harmonizer build has been fixed. (#3010)

2.7.7

Patch Changes

  • No logical changes since 2.7.5 or 2.7.6, but we fixed a bug in the release process, so we need to publish a new patch version (2.7.7). (#2999)

2.7.6

2.7.5

2.7.4

Patch Changes

  • Fixed a regression created by PR (#2967), where directives would not be properly attached to their parent. (#2982) (#2984)

2.7.3

Patch Changes

  • Fix a query planning bug where invalid subgraph queries are generated with reuseQueryFragments set true. (#2952) (#2963)

  • Fixed query planner to pass the directives from original query to subgraph operations (#2961) (#2967)

2.7.2

Patch Changes

  • When a linked directive requires a federation version higher than the linked federation spec, upgrade to the implied version and issue a hint (#2929)

  • When auto-upgrading a subgraph (i.e. one that does not explicitly @link the federation spec) do not go past v2.4. This is so that subgraphs will not inadvertently require the latest join spec (which cause the router or gateway not to start if running an older version). (#2933)

  • Add new generateQueryFragments option to query planner config (#2958)

    If enabled, the query planner will extract inline fragments into fragment definitions before sending queries to subgraphs. This can significantly reduce the size of the query sent to subgraphs, but may increase the time it takes to plan the query.

2.7.1

Patch Changes

  • Additional SourceSpecDefinition validations and bug fixes (#2914)

2.7.0

Minor Changes

  • Implement progressive @override functionality (#2911)

    The progressive @override feature brings a new argument to the @override directive: label: String. When a label is added to an @override application, the override becomes conditional, depending on parameters provided to the query planner (a set of which labels should be overridden). Note that this feature will be supported in router for enterprise users only.

    Out-of-the-box, the router will support a percentage-based use case for progressive @override. For example:

    type Query {
      hello: String @override(from: "original", label: "percent(5)")
    }

    The above example will override the root hello field from the "original" subgraph 5% of the time.

    More complex use cases will be supported by the router via the use of coprocessors/rhai to resolve arbitrary labels to true/false values (i.e. via a feature flag service).

  • Allow known FeatureDefinition subclasses to define custom subgraph schema validation rules (#2910)

  • Support @join__directive(graphs, name, args) directives (#2894)

2.6.3

2.6.2

Patch Changes

  • Avoid >= comparison for FeatureVersion objects (#2883)

  • Fix query planning bug where __typename on interface object types in named fragments can cause query plan execution to fail. (#2886) (#2886)

2.6.1

Patch Changes

  • Add missing @policy directive top level exports (#2869)

2.6.0

Minor Changes

  • Update license field in package.json to use Elastic-2.0 SPDX identifier (#2741)

  • Introduce the new @policy scope for composition (#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:

    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:

    @link(url: "https://specs.apollo.dev/feder...
Read more

@apollo/[email protected]

23 Sep 19:25
98285e5
Compare
Choose a tag to compare
Pre-release

CHANGELOG for @apollo/composition

2.9.1

Patch Changes

2.9.0

Minor Changes

  • Implements two new directives for defining custom costs for demand control. The @cost directive allows setting a custom weight to a particular field in the graph, overriding the default cost calculation. The @listSize directive gives the cost calculator information about how to estimate the size of lists returned by subgraphs. This can either be a static size or a value derived from input arguments, such as paging parameters. (#3074)

Patch Changes

2.8.5

Patch Changes

2.8.4

Patch Changes

2.8.3

Patch Changes

2.8.3-beta.2

Patch Changes

2.8.3-beta.1

Patch Changes

2.8.3-beta.0

Patch Changes

2.8.2

Patch Changes

2.8.1

Patch Changes

2.8.0

Minor Changes

  • Implement new directives to allow getting and setting context. This allows resolvers to reference and access data referenced by entities that exist in the GraphPath that was used to access the field. The following example demonstrates the ability to access the prop field within the Child resolver. (#2988)

    type Query {
      p: Parent!
    }
    type Parent @key(fields: "id") @context(name: "context") {
      id: ID!
      child: Child!
      prop: String!
    }
    type Child @key(fields: "id") {
      id: ID!
      b: String!
      field(a: String @fromContext(field: "$context { prop }")): Int!
    }

Patch Changes

2.8.0-alpha.1

Patch Changes

2.8.0-alpha.0

Minor Changes

  • Implement new directives to allow getting and setting context. This allows resolvers to reference and access data referenced by entities that exist in the GraphPath that was used to access the field. The following example demonstrates the ability to access the prop field within the Child resolver. (#2988)

    type Query {
      p: Parent!
    }
    type Parent @key(fields: "id") @context(name: "context") {
      id: ID!
      child: Child!
      prop: String!
    }
    type Child @key(fields: "id") {
      id: ID!
      b: String!
      field(a: String @fromContext(field: "$context { prop }")): Int!
    }

Patch Changes

Read more

@apollo/[email protected]

18 Sep 00:12
a7a74c5
Compare
Choose a tag to compare

@apollo/[email protected]

18 Sep 00:12
a7a74c5
Compare
Choose a tag to compare