Warn on invalid wrapped arguments #3
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
This isn't much, but it's enough to figure out how to use external SDL files. Fixes absinthe-graphql#1092
As per code [of `Absinthe.Resolution.call/2`](https://github.com/absinthe-graphql/absinthe/blob/master/lib/absinthe/resolution.ex#L204-L212) three different forms of resolution function are supported.
In OTP-25 the SDL rendering was different compared to earlier versions. I traced it down to `:digraph_utils.topsort()` although could not find a relevant change in OTP-25 that would explain the difference. `topsort/1` is used to sort the nodes in the graph so that the import process can be done in the correct order in the FieldImports phase. I've changed it to no longer rely on `topsort/1`. Since the `NoCircularFieldImports` ensures there are no cycles in the graph we can use recursion for solving the imports without ending up in an endless loop. This could be less efficient. The `topsort/1` ensured that the order of imports was such that when `A` imported `B`, `B` was already imported, etc up the hierachy chain. If `C` also imported `B`, the imports for `B` would also already be done. So, `import_fields(B)` would be called once for the entire graph. Using recursion, `import_fields(B)` would be called twice, once for `A` and once for `C`. If B itself imported other fields, those would also be called multiple times. I don't think this will be a problem in practice. The cost is only incurred for schema building, and the `import_fields` graphs are probably pretty shallow. The rendering order now matches the order the type definitions were defined in.
See absinthe-graphql#1049 The issue was not resolved for field identifiers. This issue should resolve that.
Actually when mix_doc renders it removed duplicates, keeping only the latest entry. Regardless it does not make much sense to have it two times here. I believe this was a mistake, and thus removed it. I have also checked and all others are unique and are ordered (a-z)
At the moment `Registry` is started with `compressed: true` hard coded. This presented problems when we updated absinthe some time ago, we are running an application with a large number of subscriptions and so the added CPU utilization was quite large. To avoid having to scale up we pinned absinthe to a pre-compression version. We'd like to be able to keep up to date, and so propose this change to allow users to opt-out of compression and would welcome your feedback. This PR alters the type signature of `Absinthe.Subscription.child_spec/1` so users can pass more configuration options. The original argument (a single pub-sub) is still supported for backwards compatibility.
…-and-doc-improvements Fix broken links and documentation improvements
An empty list is a valid const value. This fixes the parsing of empty lists.
Addresses issue absinthe-graphql#1149. module `Absinthe.Phase.Document.Execution.Resolution` walks the result tree and tracks `path` using a function parameter. At the same time, a `Resolution` struct is passed, which `path` field is not consistently tracked. The problem manifests itself in bogus Resolution path passed onto `resolve_type` function as described in function absinthe-graphql#1149. The reason for not updating the resolution.path in the walk process can be explained by comment of @benwilson512: `Traditionally the reason we pass in the env has more to do with making the schema available and the context available, I don't know that the other values in that struct have been validated in this situation.` Perhaps path parameter was used in the beginning and later resolution paramter was added, but not used to track current tree walk in it's path field. Nevertheless, the resolution is passed on to user code - into `resolve_type(value, resolution)` callback, which might use path to understand the context of value (eg. what is the type of parent?). This PR fixes the bookkeeping of `resolution.path` field. I have not inspected the use of other field, I am not sure which ones would change during the value walk (`parent_type` maybe?). One could consider to just use `resolution.path` instead of `path` parameter - so there is not double bookkeeping of this value. This is up to maintainers to decide, I did not make such a change.
…entation of the same
…925-error-extenstions-spec-compliance Place extra errors in extensions field
Add support for OTP-25 and Elixir 1.14
OTP 26 and Elixir 1.15
…ix/dialyzer-in-ci-elixir-1.15 Adapt to 1.15's code path pruning, for dialyxir'ing purposes
…pushes-to-same-context-id Bugfix: multiple pushes per client for subscriptions that have a `context_id`
…ble-dialyzer-ci Fix Dialyzer Cache in CI
Patches breaking change introduced in 1.7 since type mismatches throws errors beginning in 1.7. This patch does a soft fail (through Logger.warn) for newer validation logic while preserving the old validation logic.
cliftonmcintosh
force-pushed
the
cmcintosh/relax_type_name_validation
branch
from
5afb370 to
6837b46
Compare
epinault
approved these changes
Nov 17, 2023
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.
This handles another breaking change that was added in Absinthe 1.7.X. Specifically, absinthe-graphql#1138 started marking wrapped unknown types as errors.
We have clients that will start breaking with this requirement.
For example, clients are sending
UUid!when they should be sendingUuid!, and they are receiving an error with the 1.7X version of Absinthe.This PR allows us to emit warnings instead in order to give us a chance to fix those clients.