-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Description
This is only an early stage idea. Putting this here for me to investigate more later.
Today I had a very mysterious problem where a new type runtime wiring wasn't working as expected. It turns out, there was another type runtime wiring for the same type hidden away elsewhere in the codebase, but it was left unused for years. The older, incorrect type runtime wiring clobbered my new one.
This was in a Spring for GraphQL application.
RuntimeWiring in a forgotten file, written long ago:
.type(
TypeRuntimeWiring.newTypeWiring("MyInterface")
.typeResolver { ... old out of date type resolver here ...},
)RuntimeWiring in my new file:
.type(
TypeRuntimeWiring.newTypeWiring("MyInterface")
.typeResolver { ... my new type resolver here ...},
)Spring won't always load type runtime wiring in the same order, so you don't know which one will clobber the other. In my case, the new one took precedence in 10+ integration tests, then the old one took precedence in deployment. You don't want two type runtime wirings for the same type.
There are schema validation checks in Spring for GraphQL https://docs.spring.io/spring-graphql/docs/1.2.2/reference/html/#execution.graphqlsource.schema-mapping-inspection, and perhaps that's a better place to add this sort of validation. Anyway putting this here as a reminder for later.