Source gen generates invalid requests when unions have the same property name and different types

[Jacob-Steentoft]

Describe the bug

When two or more union types have the same property name but different types, ZeroQL doesn't generate a field for the unique instance of the union.

How to Reproduce

ZeroQL/src/ZeroQL.Tests/SourceGeneration/OnSyntaxTests.cs

Line 114 in 8c9883d

public async Task UnionFailing()

Request 2 union types with the same property name with different types.

Expected behavior

ZeroQL generates a temporate field for unions.

The GraphqQL schema that fails

query { posts { ... on ImageContent { imageUrl resolution } ... on TextContent { text } ... on FigureContent { figure { ... on Circle { radius } __typename } } ... on IntegerContent { text } __typename } }

Environment (please complete the following information):

• Nuget: 7.0.3
• IDE: Rider
• .Net Version 9.0.5

[byme8]

In this case the text would be int? Am I right?

on IntegerContent { text }

The HotChocolate server reports it is like an error. I am not sure that it is allowed by the GraphQL specification:

[Jacob-Steentoft]

In this case the text would be int? Am I right?

That's correct.

This issue can be resolved by changing the field name of the above query to something like the following by using named fields for selecting the data:

query {
  posts {
    ... on ImageContent {
      imageUrl
      resolution
    }
    ... on TextContent {
      text
    }
    ... on FigureContent {
      figure {
        ... on Circle {
          radius
        }
        __typename
      }
    }
    ... on IntegerContent {
      intText: text
    }
    __typename
  }
}

[Jacob-Steentoft]

So I tried to make the changes to the query generator myself, and it looks like it's not possible as using the named fields ends up changing the responding JSON model from the server, which requires the source generator to create new types for STJ to deserialize into.

Request:

{"variables":{},"query":"query { posts { ... on ImageContent { imageUrl resolution } ... on TextContent { text } ... on FigureContent { figure { ... on Circle { radius } __typename }  } ... on IntegerContent { IntText: text } __typename } }"}

Response:

{"data":{"posts":[{"imageUrl":"http://example.com/image.png","resolution":"_3840X2160","__typename":"ImageContent"},{"text":"Hello World!","__typename":"TextContent"},{"figure":{"radius":5,"__typename":"Circle"},"__typename":"FigureContent"},{"IntText":1,"__typename":"IntegerContent"}]}}

So, this looks like a big refactor to make work.

f53a888

[byme8]

Yes, it would need to generate "temporal" response schema for each request independently at build time. Then at runtime. get JSON response, map into "temporal schema", map "temporal" schema into initial one.

It starts to be complicated pretty fast.

[Jacob-Steentoft]

Is that a direction that you would be interested in taking ZeroQL? I could write a new parser that could create both query and STJ type. Which would also make the internal obsolete types redundant.

This is a feature that our team would be interested in.

[byme8]

If you want to do why not