Share response types across queries in client generator

[devin-ai-integration]

📝 Description

This PR implements deduplication and sharing of GraphQL response types across multiple queries/mutations, similar to how input types and enums are already shared.

Problem: Previously, identical response types were generated multiple times in query-specific packages (e.g., com.expediagroup.graphql.generated.firstquery.ComplexObject and com.expediagroup.graphql.generated.secondquery.ComplexObject), creating duplicate classes that required manual mapping.

Solution: Response types are now:

• Generated once in a shared .types package (e.g., com.expediagroup.graphql.generated.types)
• Deduplicated based on type name and selection set
• Reused across all queries that reference them
• Numbered when different selection sets exist (e.g., ComplexObject, ComplexObject2)

Key Changes:

1. Added sharedClassNameCache and sharedTypeToSelectionSetMap to share deduplication state across all queries
2. Modified GraphQLClientGeneratorContext to delegate to shared cache instances
3. Updated response type generation to use .types package instead of query-specific packages
4. Added objectClassToTypeSpecs map to track shared response types
5. Fixed polymorphic type (union/interface) generation to include TypeSpecs in generated files
6. Updated all test expectations (103 files) to reflect the new package structure

⚠️ Breaking Change: This changes the package structure of generated response types. Existing users will need to update imports from query-specific packages (e.g., .firstquery) to the shared .types package.

Testing:

• ✅ All existing tests pass (63 tests)
• ✅ Code quality checks pass (ktlintCheck and detekt)
• ✅ Test data migrated to verify deduplication works correctly

🔗 Related Issues

Requested by @arthurkkp-cog in Devin session 601a68caa9db4dc6ac8acc0839282f0f

---

Human Review Checklist:

• Verify response types with identical structure are truly deduplicated across queries (see kotlinx/multiple_queries/ test data where BasicInterface and ScalarWrapper are shared between FirstQuery and SecondQuery)
• Check polymorphic types (unions/interfaces) generate correctly with all implementations in a single file
• Verify types with different selection sets get unique numbered variants (see ComplexObject vs ComplexObject2 in multiple_queries test)
• Review deduplication logic in generateTypeName.kt lines 111-180 for edge cases
• Consider migration guidance for users affected by the breaking package structure change

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[chatgpt-codex-connector]

💡 Codex Review

graphql-kotlin/plugins/client/graphql-kotlin-client-generator/src/main/kotlin/com/expediagroup/graphql/plugin/client/generator/types/generateInterfaceTypeSpec.kt

Lines 185 to 279 in e791543

	private fun updateImplementationTypeSpecWithSuperInformation(
	context: GraphQLClientGeneratorContext,
	interfaceName: String,
	implementationName: String,
	implementationClassName: ClassName,
	commonProperties: List<PropertySpec>
	) {
	val commonPropertyNames = commonProperties.map { it.name }
	val implementationTypeSpec = context.typeSpecs[implementationClassName]!!
	val builder = implementationTypeSpec.toBuilder()
	val superClassName = ClassName("${context.packageName}.${context.operationName.lowercase()}", interfaceName)
	if (context.serializer == GraphQLSerializer.KOTLINX) {
	builder.addAnnotation(
	AnnotationSpec.builder(SerialName::class)
	.addMember("value = %S", implementationName)
	.build()
	)
	.superclass(superClassName)
	} else {
	builder.addSuperinterface(superClassName)
	}
	if (implementationTypeSpec.propertySpecs.isNotEmpty()) {
	val constructor = FunSpec.constructorBuilder()
	implementationTypeSpec.propertySpecs.forEach { property ->
	val updatedProperty = if (commonPropertyNames.contains(property.name)) {
	property.toBuilder().addModifiers(KModifier.OVERRIDE).build()
	} else {
	property
	}
	// add the property to the type builder only if the property was actually uptaded.
	if (updatedProperty != property) {
	builder.addProperty(updatedProperty)
	}
	constructor.addParameter(updatedProperty.name, updatedProperty.type)
	}
	builder.primaryConstructor(constructor.build())
	}
	val updatedType = builder.build()
	context.polymorphicTypes[superClassName]?.add(implementationClassName)
	context.typeSpecs[implementationClassName] = updatedType
	}
	private fun generateFallbackImplementation(context: GraphQLClientGeneratorContext, interfaceName: String, commonProperties: List<PropertySpec>): ClassName {
	val fallbackTypeName = "Default${interfaceName}Implementation"
	val superClassName = ClassName("${context.packageName}.${context.operationName.lowercase()}", interfaceName)
	val fallbackClassName = ClassName("${context.packageName}.${context.operationName.lowercase()}", fallbackTypeName)
	val fallbackType = TypeSpec.classBuilder(fallbackTypeName)
	.addAnnotation(Generated::class)
	.addKdoc("Fallback $interfaceName implementation that will be used when unknown/unhandled type is encountered.")
	.also {
	if (context.serializer == GraphQLSerializer.KOTLINX) {
	it.addAnnotation(Serializable::class)
	.superclass(superClassName)
	.addKdoc("\n\nNOTE: This fallback logic has to be manually registered with the instance of GraphQLClientKotlinxSerializer. See documentation for details.")
	} else {
	it.addSuperinterface(superClassName)
	}
	if (commonProperties.isNotEmpty()) {
	it.addModifiers(KModifier.DATA)
	}
	}
	.addProperties(
	commonProperties.map { abstractProperty ->
	abstractProperty.toBuilder()
	.initializer(abstractProperty.name)
	.addModifiers(KModifier.OVERRIDE)
	.also {
	it.modifiers.remove(KModifier.ABSTRACT)
	}
	.build()
	}
	)
	.primaryConstructor(
	FunSpec.constructorBuilder()
	.addParameters(
	commonProperties.map { propertySpec ->
	val constructorParameter = ParameterSpec.builder(propertySpec.name, propertySpec.type)
	val className = propertySpec.type as? ClassName
	if (propertySpec.type.isNullable) {
	constructorParameter.defaultValue("null")
	} else if (className != null && context.enumClassToTypeSpecs.keys.contains(className)) {
	constructorParameter.defaultValue("%M", className.member(UNKNOWN_VALUE))
	}
	constructorParameter.build()
	}
	)
	.build()
	)
	.build()
	context.polymorphicTypes[superClassName]?.add(fallbackClassName)

Interface generators still point to per-operation package

Object and interface response types are now emitted in com.expediagroup.graphql.generated.types, but generateInterfaceTypeSpec still builds superclass and fallback class names using ${context.packageName}.${context.operationName.lowercase()}. When an interface is encountered, the generated implementations and the Default…Implementation class extend/implement a type in the old query‑specific package that no longer exists, and the implementations are never registered in context.polymorphicTypes because the map is keyed by the shared package. Any client containing an interface now produces Kotlin files that reference missing types and fail to compile. The superclass package should be updated to the shared .types package before this change can work.

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".