Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

release: on branch main #2781

Merged
merged 1 commit into from
Sep 18, 2023
Merged

release: on branch main #2781

merged 1 commit into from
Sep 18, 2023

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Sep 14, 2023

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@apollo/[email protected]

Patch Changes

@apollo/[email protected]

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.

  • Don't preserve useless fetches which downgrade __typename from a concrete type back to its interface type. (#2778)

    In certain cases, the query planner was preserving some fetches which were "useless" that would rewrite **typename from its already-resolved concrete type back to its interface type. This could result in (at least) requested fields being "filtered" from the final result due to the interface's **typename in the data where the concrete type's __typename was expected.

    Specifically, the solution was compute the path between newly created groups and their parents when we know that it's trivial ([]). Further along in the planning process, this allows to actually remove the known-useless group.

  • Updated dependencies [66d7e4ce, a37bbbf6]:

@apollo/[email protected]

Patch Changes

@apollo/[email protected]

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.

  • Don't preserve useless fetches which downgrade __typename from a concrete type back to its interface type. (#2778)

    In certain cases, the query planner was preserving some fetches which were "useless" that would rewrite **typename from its already-resolved concrete type back to its interface type. This could result in (at least) requested fields being "filtered" from the final result due to the interface's **typename in the data where the concrete type's __typename was expected.

    Specifically, the solution was compute the path between newly created groups and their parents when we know that it's trivial ([]). Further along in the planning process, this allows to actually remove the known-useless group.

  • Updated dependencies []:

@apollo/[email protected]

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

@apollo/[email protected]

[email protected]

@github-actions github-actions bot requested a review from a team as a code owner September 14, 2023 22:43
@netlify
Copy link

netlify bot commented Sep 14, 2023

Deploy Preview for apollo-federation-docs canceled.

Name Link
🔨 Latest commit 350e226
🔍 Latest deploy log https://app.netlify.com/sites/apollo-federation-docs/deploys/6505bdc281750e0008585631

@codesandbox-ci
Copy link

codesandbox-ci bot commented Sep 14, 2023

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

@github-actions github-actions bot force-pushed the changeset-release/main branch 2 times, most recently from 0381f1f to 53a7815 Compare September 15, 2023 15:17
@trevor-scheer trevor-scheer merged commit f4c9f80 into main Sep 18, 2023
6 checks passed
@trevor-scheer trevor-scheer deleted the changeset-release/main branch September 18, 2023 20:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant