This rings a bell. I had this issue before. The workaround is to define a scalar type (which you already have, Tuple), make your resolver return a wrapper map with a single key, and add type serializer that accesses that key

here is an example

Custom type definition that has a serializer simply accessing a key: https://gitlab.com/arbetsformedlingen/taxonomy-dev/backend/jobtech-taxonomy-api/-/blob/main/src/clj/jobtech_taxonomy_api/db/graphql/changelog.clj?ref_type=heads#L265

And the wrapper that wraps a value, used in the resolver: https://gitlab.com/arbetsformedlingen/taxonomy-dev/backend/jobtech-taxonomy-api/-/blob/main/src/clj/jobtech_taxonomy_api/db/graphql/changelog.clj?ref_type=heads#L221

Thanks for the swift reply, @U47G49KHQ. Yes, wrapping in a map was my workaround but it doesn't look all that pretty. I thought there might be an other approach? @U04VDKC4G any ideas or ways to teach lacinia a new trick?

Lacinia execution involves a deep-merge step which takes multiple resolver results and combines them into a single value. This code is not aware of graphql types, so it cannot know that your vector is meant to be a tuple rather than a collection

Which is to say I think what you want would be difficult

Note your custom scalar can decode to a vector , but your resolvers must return something non-vector for the encoder

Which makes your scalar codecs not bijective, but maybe you really want vectors at least for input

I’m just wrapping the tuple (vector) in a map and unwrap it in the scalar’s serializer. Just like @vlaad suggested. Works fine. Thanks for the explaining the internals of lacinia.