Release @apollo/[email protected] #892
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ration (#881) This commit switches our default managed federation behavior over to our new service (named Uplink). Under the hood, this is a fairly significant change. Gateway currently handles composition of the subgraphs itself, pulling them down from GCS. Via uplink, the gateway receives the composition outright, meaning it doesn't perform any composition itself. The rules for configuring Uplink are as follows: 1. If config.schemaConfigDeliveryEndpoint is set to a string, use it 2. If config.schemaConfigDeliveryEndpoint is explicitly set to null, fallback to GCS and old behavior 3. If the env var (APOLLO_SCHEMA_CONFIG_DELIVERY_ENDPOINT) is set, use that 4. If config.schemaConfigDeliveryEndpoint is undefined, use the default uplink URL
trevor-scheer
changed the title
This is an initial implementation of support for @inaccessible when converting a composed schema to an API schema. For now, it removes any fields, object types, or interface types with an @inaccessible directive. As part of this change, buildComposedSchema no longer returns an API schema. Instead, a separate toAPISchema function is used to convert the composed schema. The reason for this is that the gateway needs the complete schema for query planning, including elements that will be removed by @inaccessible. Co-authored-by: Trevor Scheer <[email protected]> Co-authored-by: Jesse Rosenberger <[email protected]>
- [email protected] - @apollo/[email protected] - @apollo/[email protected] - @apollo/[email protected] - @apollo/[email protected]
|
|
…ror messages (#893) A type which is marked as @inaccessible and implements an interface can trigger runtime/execution errors if a resolver returns that type. That type's name will end up in the response.errors array, but it really shouldn't be leaked. This commit captures all known inaccessible type names of the format "<Name>" and field names of the format "<Name>.<Name>" and masks them in any response errors that occur during final pass graphql execution. For Name regex reference, see https://spec.graphql.org/June2018/#Name
- [email protected] - @apollo/[email protected] - @apollo/[email protected]
…aph error responses (#900) Remove query, variables, and path from downstream subgraph errors
- [email protected] - @apollo/[email protected] - @apollo/[email protected] - @apollo/[email protected] - @apollo/[email protected]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As with release PRs in the past, this is a PR tracking a release-x.y.z branch for an upcoming release of Apollo Gateway. 🙌 The version in the title of this PR should correspond to the appropriate branch.
The intention of these release branches is to gather changes which are intended to land in a specific version (again, indicated by the subject of this PR). Release branches allow additional clarity into what is being staged, provide a forum for comments from the community pertaining to the release's stability, and to facilitate the creation of pre-releases (e.g. alpha, beta, rc) without affecting the master branch.
PRs for new features might be opened against or re-targeted to this branch by the project maintainers. The master branch may be periodically merged into this branch up until the point in time that this branch is being prepared for release. Depending on the size of the release, this may be once it reaches RC (release candidate) stage with an -rc.x release suffix. Some less substantial releases may be short-lived and may never have pre-release versions.
When this version is officially released onto the latest npm tag, this PR will be merged into main.