fix(strawberry-shake): populate union member classes for fragment selections

[cliedeman]

Fixes ChilliCream#5992

Problem

When a query selects fields on union members through a named fragment whose type condition is the union itself (or another abstract type), Strawberry Shake generated member model classes that are empty: the requested fields are dropped and only __typename survives. The code still compiles, so the standard compile-check does not catch it.

This is the exact shape from the linked repro (svelue/StrawberryShakeUnionTypeBug):

query ExampleQuery {
  exampleQuery { ... ExampleUnion }
}

fragment ExampleUnion on ExampleUnion {   # type condition is the union
  ... on TypeA { fieldA }
  ... on TypeB { fieldB }
}

Selecting the same members via inline fragments directly on the union field, or via named fragments on the concrete members, already worked. Only the named-fragment-on-the-abstract-type path was broken.

Root cause

FragmentHelper.CollectFields (src/StrawberryShake/CodeGeneration/src/CodeGeneration/Analyzers/FragmentHelper.cs:311) builds the field set for a concrete union member. It descended into inline fragment nodes but not into named fragment nodes whose type condition is an abstract type.

A named fragment on the union does not get its own interface for a concrete member (RewriteForConcreteType only rewrites interface conditions, and a union is neither object nor interface), so the member inline fragments nested inside it were never visited. The member interface ended up with no fields, and CreateClass then filters the (correctly collected) selectionSet.Fields down to the interface field names, producing an empty class.

Fix

In CollectFields, additionally descend into named fragment nodes whose abstract type condition applies to the concrete member type, so the nested member selections are reached. Inline-fragment and concrete-named-fragment paths are unchanged.

Evidence of no regression: every existing integration *.Client.cs snapshot (including StarWarsUnionListTest, StarWarsTypeNameOnUnionsTest, StarWarsTypeNameOnInterfacesTest, fragment + include/skip, hero traits) is byte-identical after the change. The fix only adds the previously-missing fields.

Tests

New UnionTypeGeneratorTests drives CSharpGenerator.Generate directly and asserts the generated member classes contain the requested properties (the previous empty output still compiled, so source-level assertions are required). It covers three selection shapes:

• inline fragments on the union field (was passing) — regression guard
• a named fragment on the union (was failing) — the bug
• named fragments on the members (was passing) — regression guard

Verified red before the fix (only the named-fragment-on-union case failed) and green after. Ran the surrounding generator and integration test classes (140+ tests) with no regressions.

— Claude
🤖 Generated with Claude Code