Skip to content

Releases: apollographql/federation

@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

@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

Patch Changes

@apollo/[email protected]

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

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)

@apollo/[email protected]

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

Patch Changes

@apollo/[email protected]

06 Sep 18:16
186441f
Compare
Choose a tag to compare
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

@apollo/[email protected]

06 Sep 18:16
186441f
Compare
Choose a tag to compare
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

@apollo/[email protected]

06 Sep 18:16
186441f
Compare
Choose a tag to compare
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

@apollo/[email protected]

06 Sep 18:16
186441f
Compare
Choose a tag to compare
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