Skip to content

Releases: apollographql/federation

@apollo/[email protected]

06 Sep 18:16
@github-actions github-actions
@apollo/[email protected]
186441f
This commit was signed with the committer’s verified signature.
nicholascioli Nicholas Cioli
GPG key ID: 9E26529FF602A9BD
Learn about vigilant mode.
Compare
Choose a tag to compare
@apollo/[email protected] Pre-release
Pre-release

CHANGELOG for @apollo/subgraph

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 []:

2.5.4

Patch Changes

2.5.3

Patch Changes

Read more
Assets 2
Loading

@apollo/[email protected]

06 Sep 18:16
@github-actions github-actions
@apollo/[email protected]
186441f
This commit was signed with the committer’s verified signature.
nicholascioli Nicholas Cioli
GPG key ID: 9E26529FF602A9BD
Learn about vigilant mode.
Compare
Choose a tag to compare
@apollo/[email protected] Pre-release
Pre-release

CHANGELOG for @apollo/query-planner

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 definitions. Specifically, subsequent fragment "candidates" with the same type condition and the same length of selections as a previous fragment weren't correctly added to the list of fragments. An example of an affected query is:

    query {
  t {
    ... on A {
      x
      y
    }
  }
  t2 {
    ... on A {
      y
      z
    }
  }
}

...

Read more

Contributors

tag, defer, and 3 other contributors
Assets 2
Loading

@apollo/[email protected]

06 Sep 18:16
@github-actions github-actions
@apollo/[email protected]
186441f
This commit was signed with the committer’s verified signature.
nicholascioli Nicholas Cioli
GPG key ID: 9E26529FF602A9BD
Learn about vigilant mode.
Compare
Choose a tag to compare
@apollo/[email protected] Pre-release
Pre-release

CHANGELOG for @apollo/query-graphs

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 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 l...

Read more

Contributors

provides
Assets 2
Loading

@apollo/[email protected]

06 Sep 18:16
@github-actions github-actions
@apollo/[email protected]
186441f
This commit was signed with the committer’s verified signature.
nicholascioli Nicholas Cioli
GPG key ID: 9E26529FF602A9BD
Learn about vigilant mode.
Compare
Choose a tag to compare
@apollo/[email protected] Pre-release
Pre-release

CHANGELOG for @apollo/gateway

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

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)

  • Updated dependencies [[bee0b0828b4fb6a1d3172ac330560e2ab6c046bb](bee0b0828b4fb6a1d3172ac330560...

Read more

Contributors

tag, defer, and 2 other contributors
Assets 2
Loading

@apollo/[email protected]

06 Sep 18:16
@github-actions github-actions
@apollo/[email protected]
186441f
This commit was signed with the committer’s verified signature.
nicholascioli Nicholas Cioli
GPG key ID: 9E26529FF602A9BD
Learn about vigilant mode.
Compare
Choose a tag to compare
@apollo/[email protected] Pre-release
Pre-release

CHANGELOG for @apollo/federation-internals

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/federation/v2.6", import: [..., "@policy"])

2.5.7

2.5.6

Patch Changes

  • Fixing issue where redeclaration of custom scalars in a fed1 schema may cause upgrade errors (#2809)

2.5.5

2.5.4

2.5.3

Patch Changes

  • Modifies the type for the argument of the @requiresScopes from `[federation__Scope!]!...
Read more

Contributors

tag, inaccessible, and 3 other contributors
Assets 2
Loading

@apollo/[email protected]

06 Sep 18:16
@github-actions github-actions
@apollo/[email protected]
186441f
This commit was signed with the committer’s verified signature.
nicholascioli Nicholas Cioli
GPG key ID: 9E26529FF602A9BD
Learn about vigilant mode.
Compare
Choose a tag to compare
@apollo/[email protected] Pre-release
Pre-release

CHANGELOG for @apollo/composition

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

2.7.8

Patch Changes

2.7.7

Patch Changes

  • No logical changes since 2.7.5 or 2.7.6, but we fixed a bug in th...
Read more

Contributors

tag, external, and Shareable
Assets 2
Loading

@apollo/[email protected]

27 Aug 18:14
@github-actions github-actions
@apollo/[email protected]
351f80c
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
@apollo/[email protected]

Patch Changes

Assets 2
Loading

@apollo/[email protected]

27 Aug 18:14
@github-actions github-actions
@apollo/[email protected]
351f80c
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
@apollo/[email protected]

Patch Changes

Assets 2
Loading

@apollo/[email protected]

27 Aug 18:14
@github-actions github-actions
@apollo/[email protected]
351f80c
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
@apollo/[email protected]

Patch Changes

Assets 2
Loading

@apollo/[email protected]

27 Aug 18:14
@github-actions github-actions
@apollo/[email protected]
351f80c
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
@apollo/[email protected]

Patch Changes

Assets 2
Loading