Tracking: Strawberry Shake fragment/codegen fixes from differential fuzzing (PRs #7-#12)

[cliedeman]

Tracking: Strawberry Shake fragment/codegen fixes from differential fuzzing

Consolidated tracker for a batch of Strawberry Shake code-generation findings, their fixes, related upstream issues, and verification against upstream vnext. Fix branches are based on main (which mirrors upstream ChilliCream/graphql-platform), so each PR is an isolated, upstream-style change.

How found: a differential codegen fuzzer (graphql-js validity oracle → real CSharpGenerator.Generate(...) → Roslyn-compile of the output). A finding = a spec-valid document that Strawberry Shake throws on, errors on, or emits non-compiling/wrong code for. Targets derived from stackworx/relay-extractor. Harness + write-up: branch test/strawberry-shake-codegen-fuzz (FINDINGS.md). Companion HotChocolate-validator findings: #6.

---

Status at a glance

Fixes shipped (each TDD-first: failing test → fix → PR)

#	Item	PR	Status	In vnext ChilliCream#9977?	Upstream
1	Generator throw: composite field selected directly and via a fragment	#9	✅ fixed	❌ still broken	new (unreported)
2	CS0528: same named fragment spread ≥2×	#7	✅ fixed	❌ still broken	new (unreported)
3	Inline-fragment order / entity referenced twice drops data	#11	✅ fixed	❌ still broken	Fixes ChilliCream#8063
4	Union members via a named fragment → empty classes	#8	✅ fixed	❌ still broken	Fixes ChilliCream#5992
5	Same fragment across operations → duplicate per-op models	#10	🟡 characterizing test + analysis only	❌ still broken	Relates ChilliCream#6873
6	Unknown __typename throws at runtime	#12	✅ fixed	❌ still broken	Fixes ChilliCream#6415

Second batch — duplicate-member family (shipped)

Item	PR	Status	Upstream
Multiple uploads / file inputs → duplicate members (CS0128 'u' + duplicate MapFilesFromType<T>)	#14	✅ fixed	Fixes ChilliCream#9559, ChilliCream#7852
Schema inheritance → "base class already defined"	#15	✅ already fixed on main → regression guard	Relates ChilliCream#5593

Verified already-fixed on main (no action needed)

• Missing deserialization for fragments in query that has the same field multiple times ChilliCream/graphql-platform#6130 (same field requested multiple times) — no longer reproduces on current main; both aliases generate full per-implementation deserialization. Not related to PR fix(strawberryshake): preserve entity fields across differing selection sets (#8063) #11 (different code path). Recommend closing upstream as already-fixed (see comment).
• StrawberryShake v13 not generating source for schema with inheritance ChilliCream/graphql-platform#5593 (shared interface → "base class already defined") — no longer reproduces on current main (fixed by the type-system pipeline rework, e.g. Groundwork to align type systems. ChilliCream/graphql-platform#8247/Introduced new execution abstractions. ChilliCream/graphql-platform#8267, not a targeted commit). Issue still open upstream; PR test(strawberry-shake): regression guard for inheritance codegen (#5593) #15 adds a regression guard. Candidate to close as already-fixed.

---

Detail (shipped fixes)

1. fix(strawberryshake): resolve output type for composite field selected directly and via fragment #9 — a composite field selected directly + via a fragment threw InvalidOperationException: Could not find an output type for the specified field syntax. Root cause: FieldCollector merges duplicate selections in document order while FragmentHelper.CollectFields processes inline fragments first; they disagree on the canonical FieldNode and OperationModel.TryGetFieldResultType's reference-equality lookup misses. Fix registers the merged-away selection sets. 194 passed, no existing snapshot changed.
2. fix(strawberryshake): dedupe duplicate fragment spreads in interface list (CS0528) #7 — ...UF ...UF listed the fragment interface twice (: IUF, IUF) → CS0528. Root cause: FragmentHelper.CreateImplements adds the cached interface once per spread. Fix dedupes. 195 passed.
3. fix(strawberryshake): preserve entity fields across differing selection sets (#8063) #11 — entity referenced twice with differing selection sets had fields overwritten with default! by the JSON result builder. Fix hoists ctor args + merges preserved fields in JsonResultBuilderGenerator_UpdateEntity.cs. Aligns with upstream draft Adjust result builder to not return incomplete data from the entity store ChilliCream/graphql-platform#8595. 47 snapshots + 13 clients regenerated.
4. fix(strawberry-shake): populate union member classes for fragment selections #8 — union members selected via a named fragment on the union got empty classes. Root cause: FragmentHelper.CollectFields didn't descend into named-fragment nodes with an abstract type condition. 14-line fix.
5. test(strawberry-shake): characterize shared-fragment model naming gap (#6873) #10 — same fragment across two operations generates divergent GetA_* / GetB_* models (only the fragment interface is shared). Full fix is large/risky (operation+path-keyed names, no cross-op registry, ~86 snapshots); ships a characterizing test + scope analysis instead, no production change.
6. fix(strawberryshake): degrade gracefully on unknown abstract type at runtime #12 — unknown union/interface __typename made the result builder throw new NotSupportedException(). Fix makes the per-__typename dispatch nullability-aware (degrade to null for nullable positions) across JsonResultBuilderGenerator*. 73 snapshots + 13 clients regenerated.

Merge-order note: #7 & #8 both touch FragmentHelper.cs (different methods); #11 & #12 both touch JsonResultBuilderGenerator* and regenerate large snapshot sets (47 and 73) — whichever of #11/#12 merges second needs its snapshots re-regenerated.

---

vnext (ChilliCream#9977) verification

Ran every repro against the StrawberryShake vnext PR head (a724f9b282). vnext fixes none of the six (see the "In vnext ChilliCream#9977?" column and the full comment). Caveat: that is an early PR head; vnext may address some as it matures. As of that head, all fork PRs remain relevant.

---

Backlog — related open defects found in the upstream sweep (not yet addressed)

• Duplicate-member family (same class as fix(strawberryshake): dedupe duplicate fragment spreads in interface list (CS0528) #7): Strawberry shake generating duplicate members when multiple File Inputs exist on the same type ChilliCream/graphql-platform#9559 + Strawberry Shake generates invalid C# for mutations with multiple uploads ChilliCream/graphql-platform#7852 done (fix(strawberry-shake): generate compilable upload mappers for multiple Upload fields #14), StrawberryShake v13 not generating source for schema with inheritance ChilliCream/graphql-platform#5593 done (test(strawberry-shake): regression guard for inheritance codegen (#5593) #15, already-fixed / regression guard); Bug when deserializing multiple custom scalars to same type ChilliCream/graphql-platform#6378 (custom scalars deserialized to same type) remaining.
• Interface / __typename result-type family (adjacent to Generated union type classes are empty with SS13.0.5 and .NET7 when using fragments ChilliCream/graphql-platform#5992/Unknown interface types in result list throws exception ChilliCream/graphql-platform#6415/Order of Inline Fragments Causes Missing Data ChilliCream/graphql-platform#8063): Build Error - Incompatible Type Conversion in Generated Code  ChilliCream/graphql-platform#6743, Generation fails for interface types which has an id field ChilliCream/graphql-platform#6539, "Cannot convert error" in generated StrawberryShake code for implemented result types ChilliCream/graphql-platform#6292, Strawberry Shake: Runtime ArgumentNullException caused by possible code generation bug when mapping response into "Data" object ChilliCream/graphql-platform#5349.
• Other won't-compile: Strawberry Shake: Code generation fails when GraphQL field names conflict with System.Object method names ChilliCream/graphql-platform#8934 (field name vs System.Object method), Strawberry Shake generates random ">" character in function name leading to invalid generated code. ChilliCream/graphql-platform#7766 (stray ">" in generated name).
• Runtime missing-data: Strawberry Shake: fails to map properties from GraphQL response to .NET result object, resulting in .NET null values ChilliCream/graphql-platform#5256.

Findings 1 & 2 confirmed unreported upstream (exhaustive open+closed search). Full sweep: comment.

---

Checklist

• fix(strawberryshake): resolve output type for composite field selected directly and via fragment #9 — Finding 1 (output-type lookup) — fixed, review
• fix(strawberryshake): dedupe duplicate fragment spreads in interface list (CS0528) #7 — Finding 2 (CS0528) — fixed, review
• fix(strawberryshake): preserve entity fields across differing selection sets (#8063) #11 — Order of Inline Fragments Causes Missing Data ChilliCream/graphql-platform#8063 (entity double-reference) — fixed, review
• fix(strawberry-shake): populate union member classes for fragment selections #8 — Generated union type classes are empty with SS13.0.5 and .NET7 when using fragments ChilliCream/graphql-platform#5992 (union fragment empty) — fixed, review
• test(strawberry-shake): characterize shared-fragment model naming gap (#6873) #10 — Generating predictable model classes in strawberry shake ChilliCream/graphql-platform#6873 (shared fragment models) — analysis only, decide scope
• fix(strawberryshake): degrade gracefully on unknown abstract type at runtime #12 — Unknown interface types in result list throws exception ChilliCream/graphql-platform#6415 (unknown __typename) — fixed, review
• fix(strawberry-shake): generate compilable upload mappers for multiple Upload fields #14 — duplicate-member: Strawberry shake generating duplicate members when multiple File Inputs exist on the same type ChilliCream/graphql-platform#9559 / Strawberry Shake generates invalid C# for mutations with multiple uploads ChilliCream/graphql-platform#7852 (uploads) — fixed, review
• test(strawberry-shake): regression guard for inheritance codegen (#5593) #15 — StrawberryShake v13 not generating source for schema with inheritance ChilliCream/graphql-platform#5593 (inheritance) — already fixed on main, regression guard added
• Missing deserialization for fragments in query that has the same field multiple times ChilliCream/graphql-platform#6130 — verified already-fixed on main
• vnext StrawberryShake vnext ChilliCream/graphql-platform#9977 — verified (fixes none)

— Claude
🤖 Generated with Claude Code

[cliedeman]

Follow-up: exhaustive upstream issue sweep

Swept all 99 open 🌶️ strawberry shake issues + targeted full-text search (OPEN and CLOSED) for fragments, aliases, union/interface result codegen, generator crashes, non-compiling generated code (CS####), duplicate/empty/missing members, __typename, and result deserialization. All issue numbers below verified by hand.

Findings 1 & 2 — confirmed unreported

Exhaustive search for the exact symptoms (CS0528 / "already listed in interface" / "Could not find an output type for the specified field syntax") returned zero Strawberry Shake matches. One nuance worth a fresh upstream report: ChilliCream#6907 (CLOSED, completed) is the same query shape as Finding 1 (a field selected directly + via a named spread) but was reported as runtime missing-properties, not the generator crash we hit — so our Finding 1 may be a regression or uncovered sub-case of an issue thought fixed.

Likely overlaps with our PRs (worth checking)

• Missing deserialization for fragments in query that has the same field multiple times ChilliCream/graphql-platform#6130 (open) "Missing deserialization for fragments in query that has the same field multiple times" — same entity/selection-merge family as Order of Inline Fragments Causes Missing Data ChilliCream/graphql-platform#8063 / PR fix(strawberryshake): preserve entity fields across differing selection sets (#8063) #11. Worth checking whether PR fix(strawberryshake): preserve entity fields across differing selection sets (#8063) #11's entity-merge fix already resolves it.
• Empty Fragments in Response ChilliCream/graphql-platform#6452 (closed, self-resolved by reporter) and Strawberry shake creates multiple interfaces for same interface ChilliCream/graphql-platform#1919 (closed "use fragments") — the underlying behaviours map to Generated union type classes are empty with SS13.0.5 and .NET7 when using fragments ChilliCream/graphql-platform#5992 and Generating predictable model classes in strawberry shake ChilliCream/graphql-platform#6873 respectively, i.e. those concerns are still effectively live.

New, open, related defects we did NOT address (follow-up candidates)

Duplicate-member / won't-compile family (same defect class as Finding 2 / PR #7):

• Strawberry shake generating duplicate members when multiple File Inputs exist on the same type ChilliCream/graphql-platform#9559 (open) duplicate members when multiple File Inputs on one type (won't compile, recent, repro)
• Strawberry Shake generates invalid C# for mutations with multiple uploads ChilliCream/graphql-platform#7852 (open) multiple uploads → CS0128 'u' already defined (won't compile; likely same root cause as Strawberry shake generating duplicate members when multiple File Inputs exist on the same type ChilliCream/graphql-platform#9559)
• StrawberryShake v13 not generating source for schema with inheritance ChilliCream/graphql-platform#5593 (open) schema with inheritance → "base class already defined" (generator fails)
• Bug when deserializing multiple custom scalars to same type ChilliCream/graphql-platform#6378 (open) multiple custom scalars deserialized to the same type → overlapping Deserialize
• (Member with the same signature is already declared ChilliCream/graphql-platform#8701 closed, "Member with the same signature is already declared" — same family, no visible fix)

Interface / union / __typename result-type family (adjacent to ChilliCream#5992 / ChilliCream#6415 / ChilliCream#8063):

• Build Error - Incompatible Type Conversion in Generated Code  ChilliCream/graphql-platform#6743 (open) CS1503 conversion when selecting only __typename under an interface (won't compile)
• Generation fails for interface types which has an id field ChilliCream/graphql-platform#6539 (open) generation fails for interface types that have an id field
• "Cannot convert error" in generated StrawberryShake code for implemented result types ChilliCream/graphql-platform#6292 (open) "cannot convert" for implemented result types (won't compile)
• Strawberry Shake: Runtime ArgumentNullException caused by possible code generation bug when mapping response into "Data" object ChilliCream/graphql-platform#5349 (open) runtime ArgumentNullException mapping response into Data when an interface has multiple implementations

Other won't-compile:

• Strawberry Shake: Code generation fails when GraphQL field names conflict with System.Object method names ChilliCream/graphql-platform#8934 (open) field name collides with a System.Object method (e.g. equals)
• Strawberry Shake generates random ">" character in function name leading to invalid generated code. ChilliCream/graphql-platform#7766 (open) generator emits a stray ">" in a function name → invalid C#

Runtime missing-data:

• Strawberry Shake: fails to map properties from GraphQL response to .NET result object, resulting in .NET null values ChilliCream/graphql-platform#5256 (open) nested properties not mapped → null values

Bottom line

No exact duplicate of our six was missed, and Findings 1 & 2 are confirmed unreported. But there is a substantial cluster of open, reproducible won't-compile generator defects in the same two families as our fixes: the duplicate-member family (ChilliCream#9559, ChilliCream#7852, ChilliCream#5593, ChilliCream#6378) mirrors Finding 2 / PR #7, and the interface/__typename result-type family (ChilliCream#6743, ChilliCream#6539, ChilliCream#6292, ChilliCream#5349) sits alongside ChilliCream#5992 / ChilliCream#6415 / ChilliCream#8063. These are the strongest candidates for a follow-up batch.

— Claude
🤖 Generated with Claude Code

[cliedeman]

Verified against StrawberryShake vnext (upstream PR ChilliCream#9977)

Checked out PR ChilliCream#9977 (head a724f9b282, "Add Mutable to StrawberryShake (ChilliCream#9976)") into a worktree and ran our repros against vnext's own generator. vnext keeps the same codegen API + test harness (CSharpGenerator.Generate, DocumentAnalyzer, SchemaHelper, AssertResult all intact; CodeGeneration diff is only ~50 files), so our runner ported directly.

Result: ChilliCream#9977 fixes none of the six.

Item	vnext	Evidence
Finding 1	❌ not fixed	Generator still throws InvalidOperationException: Could not find an output type for the specified field syntax (generation-time, independent of compile refs).
Finding 2	❌ not fixed	Generated result type still lists the fragment interface twice → CS0528: 'IUF' is already listed in interface list.
ChilliCream#5992	❌ not fixed	Union member class generated via a named fragment on the union is still empty: U5992b_Pet_Dog has a parameterless ctor and no Name/BarkVolume. (The inline-fragment variant works, as it always did.)
ChilliCream#6873	❌ not fixed	Still separate per-operation models GetA_Me_User vs GetB_Users_Edges_Node_User (with separate entity mappers); only the ISF fragment interface is shared.
ChilliCream#6415	❌ not fixed	Generated result builder still ends its per-__typename dispatch with throw new NotSupportedException(), so an unknown concrete type throws instead of degrading.
ChilliCream#8063	❌ not fixed (code-level)	Generated entity update still uses the default ! new-entity pattern that PR #11 targets (existing-entity branch merges, new-entity branch defaults absent fields). Runtime data-loss was not re-executed, but the targeted code path is identical to main; PR #11's fix is absent.

Also: anonymous operations are still rejected (All operations must be named).

Caveats

• This is an early PR head (the Add Mutable commit; CodeGeneration diff ~50 files), so vnext may address some of these as it evolves. As of this head, all six fork PRs (fix(strawberryshake): dedupe duplicate fragment spreads in interface list (CS0528) #7-fix(strawberryshake): degrade gracefully on unknown abstract type at runtime #12) remain relevant and are not superseded.
• vnext's generated DI code references BuildServiceProvider (ServiceCollectionContainerBuilderExtensions); against our standalone Roslyn compile harness this surfaced as a uniform CS0234 (even on a trivial query), i.e. a reference-resolution artifact of the harness, not a vnext defect. Generation-time and source-level signals (used above) are unaffected by it.

Method: ported HcCodegenRunner onto the ChilliCream#9977 worktree, ran the minimization probes + targeted source dumps of the generated clients.

— Claude
🤖 Generated with Claude Code

[cliedeman]

ChilliCream#6130 checked — PR #11 does not resolve it, and it appears already fixed on main

Question: does PR #11 (the ChilliCream#8063 entity-merge fix) also resolve #6130 ("Missing deserialization for fragments in query that has the same field multiple times")?

Reproduced ChilliCream#6130's exact shape locally — the same interface-typed field aliased twice with different args and different type fragments:

query GetMultiple {
  firstAlias: node(id: "foo") { __typename ... on User { id name } }
  secondAlias: node(id: "bar") { __typename ... on Dog { id barkVolume } }
}

• PR fix(strawberryshake): preserve entity fields across differing selection sets (#8063) #11 branch (fix/ss-inline-fragment-order-missing-data): both aliases generate a full set of per-implementation classes with the correct fields — GetMultiple_FirstAlias_User(__typename, id, name) and GetMultiple_SecondAlias_Dog(__typename, id, barkVolume) — the second alias's deserializer has the Dog __typename branch, and a GetMultiple_SecondAlias_DogFromDogEntityMapper is generated. The Missing deserialization for fragments in query that has the same field multiple times ChilliCream/graphql-platform#6130 symptom (second alias missing its fragment-type deserialization → factory ArgumentNullException) does not reproduce.
• Plain main (no Order of Inline Fragments Causes Missing Data ChilliCream/graphql-platform#8063 fix): materially the same output for the deserialization dispatch — GetMultiple_SecondAlias_Dog with its fields and the Dog branch are present.

Conclusion

• PR fix(strawberryshake): preserve entity fields across differing selection sets (#8063) #11 does not "resolve" Missing deserialization for fragments in query that has the same field multiple times ChilliCream/graphql-platform#6130 — it's an unrelated code path. PR fix(strawberryshake): preserve entity fields across differing selection sets (#8063) #11 only changes the entity-store construction inside each __typename branch; Missing deserialization for fragments in query that has the same field multiple times ChilliCream/graphql-platform#6130 is about whether the per-alias deserialization branches/classes are generated at all, which they now are.
• Missing deserialization for fragments in query that has the same field multiple times ChilliCream/graphql-platform#6130 (filed against v13.1.0) no longer reproduces on current main — it appears already fixed by generator evolution. Recommended action: confirm with a runtime repro and close Missing deserialization for fragments in query that has the same field multiple times ChilliCream/graphql-platform#6130 upstream as already-fixed, rather than write a new fix.

This was a static/source-level check (the generated deserializers + entity mappers are present for both aliases, identical on main and PR #11). A runtime execution test would make the "already fixed" call airtight.

— Claude
🤖 Generated with Claude Code