You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While it's a bit niche, we have a use case where we want to return Query from an object field (specifically this is in a mutation result to allow callers to request arbitrary parts of the schema after a mutation).
This works fine on a standard strawberry.Schema, but breaks down when using strawberry.federation.Schema.
Reproduction
This works fine without federation, for example this minimal test case:
error: Type `Query` is defined multiple times in the schema
@ test/schema_federated.py:7
6 | @strawberry.type
❱ 7 | class Query:
^^^^^ first class defined here
8 | @strawberry.field
9 | def foo(self) -> Foo:
10 | return Foo()
To fix this error you should either rename the type or remove the duplicated definition.
Read more about this error on https://errors.strawberry.rocks/duplicated-type-name
(the link isn't useful here as the issue isn't non unique names)
I've tracked it down to how the federation schema works, specifically _get_federation_query_type (1) which creates a new type that's purely internal and when the converter tries to match them up in validate_same_type_definition (2) the types aren't the same anymore, one is the type as defined in the consumer python module and the other is the internal type to which the federation fields have been added. When we reach the raise statement (3), the values extracted from the rich formatted exception are:
This feels like it should be supported with or without federation but as far as I could find, there's no currently supported way to have a field type be a forward reference to "the final Query type".
We haven't found a solution we're happy with yet, but it looks like either extracting the bits creating the new type so we can get a hold of a reference to the type or possibly a custom SchemaConverter could work as a workaround (will update when we have something working, hoping there's something that can be turned into a PR but reporting for now for tracking).
Also to note using lazy here doesn't help as it requires an importable type, but a variation/expansion on the lazy concept could work to express "reference to the final schema type", although probably can't be made type safe.
System Information
Operating system: Mac OS (but don't think that will matter here)
Strawberry version (if applicable): Latest version
Upvote & Fund
We're using Polar.sh so you can upvote and help fund this issue.
We receive the funding once the issue is completed & confirmed by you.
Thank you in advance for helping prioritize & fund our backlog.
The text was updated successfully, but these errors were encountered:
While it's a bit niche, we have a use case where we want to return
Query
from an object field (specifically this is in a mutation result to allow callers to request arbitrary parts of the schema after a mutation).This works fine on a standard
strawberry.Schema
, but breaks down when usingstrawberry.federation.Schema
.Reproduction
This works fine without federation, for example this minimal test case:
Works fine (either run
python <file>
orstrawberry export-schema <module>:schema
).However if you use the federation integration:
You get:
(the link isn't useful here as the issue isn't non unique names)
I've tracked it down to how the federation schema works, specifically
_get_federation_query_type
(1) which creates a new type that's purely internal and when the converter tries to match them up invalidate_same_type_definition
(2) the types aren't the same anymore, one is the type as defined in the consumer python module and the other is the internal type to which the federation fields have been added. When we reach the raise statement (3), the values extracted from therich
formatted exception are:and:
This feels like it should be supported with or without federation but as far as I could find, there's no currently supported way to have a field type be a forward reference to "the final
Query
type".We haven't found a solution we're happy with yet, but it looks like either extracting the bits creating the new type so we can get a hold of a reference to the type or possibly a custom
SchemaConverter
could work as a workaround (will update when we have something working, hoping there's something that can be turned into a PR but reporting for now for tracking).Also to note using
lazy
here doesn't help as it requires an importable type, but a variation/expansion on thelazy
concept could work to express "reference to the final schema type", although probably can't be made type safe.System Information
Upvote & Fund
The text was updated successfully, but these errors were encountered: