Fix non-deterministic generated code involving interfaces and fragmen…

…ts. (#323)

In #209, @vikstrous2 added a bugfix to sort the list of interfaces when
generating code, so the generated output was stable. This worked great,
but there was one more case where we need to do that, involving
interfaces in fragments.

I have:
- [x] Written a clear PR title and description (above)
- [x] Signed the [Khan Academy CLA](https://www.khanacademy.org/r/cla)
- [x] Added tests covering my changes, if applicable
- [ ] Included a link to the issue fixed, if applicable
- [ ] Included documentation, for new features
- [x] Added an entry to the changelog

docs/CHANGELOG.md

@@ -36,8 +36,9 @@ Note that genqlient is now tested from Go 1.20 through Go 1.22.
 ### Bug fixes:
 - The presence of negative pointer directives, i.e., `# @genqlient(pointer: false)` are now respected even in the when `optional: pointer` is set in the configuration file.
 - Made name collisions between query/mutation arguments and local function variables less likely.
-- Fix generation issue related to golang type implementation of complex graphql union fragments
+- Fix generation issue related to golang type implementation of complex graphql union fragments.
 - Bind correctly to types in the same package as the generated code.
+- Fix non-deterministic generated code when querying graphql interfaces via named fragments.
 
 ## v0.6.0
 

generate/convert.go

@@ -841,6 +841,8 @@ func (g *generator) convertNamedFragment(fragment *ast.FragmentDefinition) (goTy
 		return goType, nil
 	case ast.Interface, ast.Union:
 		implementationTypes := g.schema.GetPossibleTypes(typ)
+		// Make sure we generate stable output by sorting the types by name when we get them
+		sort.Slice(implementationTypes, func(i, j int) bool { return implementationTypes[i].Name < implementationTypes[j].Name })
 		goType := &goInterfaceType{
 			GoName:          fragment.Name,
 			SharedFields:    fields,