Code of Conduct
AI Policy
Versions
elixir 1.18.4
ash 3.6.2
ash_graphql 1.8.3
Operating system
Linux docker container on macOS
Current Behavior
I haven't verified all different potential iterations of this bug, but I have an application that does not make use of graphql subscriptions. I recently added a resource modeling a "subscription" within my application, and named its graphql type :subscription. I noticed that in the generated graphql schema file, the schema now had a subscription key in the root schema, like this:
schema {
mutation: RootMutationType
query: RootQueryType
subscription: Subscription
}
with type Subscription having my subscription resource's fields
where it had previously (and still does if I change the type name to anything other than subscription) looked like this:
schema {
mutation: RootMutationType
query: RootQueryType
}
I assume this is because Subscription is effectively a reserved type name for graphql subscriptions. I'm not sure what would happen here if this occurred in an application that did use graphql subscriptions, but I suspect these would overlap in a more catastrophic way (my application did still compile).
Reproduction
- create a resource called
MyApp.Domain.Subscription with any attributes
- it should use the
AshGraphql.Resource extension, have a graphql type of :subscription, and wire up a query of some sort so it does show up in the schema file
- generate the sdl file
- see the behavior described
Expected Behavior
I think the easiest way to avoid this would be to simply raise if a graphql type is called subscription, since that type name is effectively reserved by ash_graphql.
The name of the internal subscription type could also be made configurable, which would allow users to name a type subscription if they explicitly rename the internal subscription type.
Code of Conduct
AI Policy
Versions
elixir 1.18.4
ash 3.6.2
ash_graphql 1.8.3
Operating system
Linux docker container on macOS
Current Behavior
I haven't verified all different potential iterations of this bug, but I have an application that does not make use of graphql subscriptions. I recently added a resource modeling a "subscription" within my application, and named its graphql type
:subscription. I noticed that in the generated graphql schema file, the schema now had a subscription key in the root schema, like this:with
type Subscriptionhaving my subscription resource's fieldswhere it had previously (and still does if I change the type name to anything other than
subscription) looked like this:I assume this is because
Subscriptionis effectively a reserved type name for graphql subscriptions. I'm not sure what would happen here if this occurred in an application that did use graphql subscriptions, but I suspect these would overlap in a more catastrophic way (my application did still compile).Reproduction
MyApp.Domain.Subscriptionwith any attributesAshGraphql.Resourceextension, have a graphqltypeof:subscription, and wire up a query of some sort so it does show up in the schema fileExpected Behavior
I think the easiest way to avoid this would be to simply raise if a graphql type is called
subscription, since that type name is effectively reserved by ash_graphql.The name of the internal subscription type could also be made configurable, which would allow users to name a type
subscriptionif they explicitly rename the internal subscription type.