Inconsistent EnumValue coercion

As part of moving our schema to a full(ish) IDL version.

We’re facing some issue with enum coercion. We defined a @enum directive to be able to override the value a of an enum using the IDL, that part is working nicely. Nevertheless, when coercing the enum from an input object we can’t get the custom value.

As result of applying the directive we are overriding enumValue from DefaultAstSchemaBuilder

  override def enumValue(definition: EnumValueDefinition): String = {
    definition.directives.collectFirst { case EnumDirective(d) => d.value }.getOrElse(super.enumValue(definition))
  }

This is the schema we’re using to test it.

enum SomeEnum {
  FOO @enum(value: "foo_value")
  BAR @enum(value: "bar_value")
}

input SomeInput {
  inputEnum: SomeEnum
}

Let’s say we use FOO in two different mutations with different input args, this are the scenarios we are testing:

Scenario 1

The enum is a direct argument of the mutation.

extend type Mutation {
  aMutation(inputEnum: SomeEnum): SuchPayload
}

In this case, doing ctx.arg("input") will return foo_value

Scenario 2

The enum is a child of a complex type. This is the real use case, what we’ll be using.

extend type Mutation {
  anotherMutation(input: SomeInput): SuchPayload
}

In this case, doing ctx.arg("input") will return the following json

{ "inputEnum": "FOO" }

which is misleading, as in one case the enum value is coerced and in the other one it doesn’t.

Current status

We tried to track down the issue through sangria codebase, and we reach to this point

https://github.com/sangria-graphql/sangria/blob/master/src/main/scala/sangria/execution/ValueCoercionHelper.scala#L329-L334

where case raw returns foo_value and case standard returns FOO. Eventually, I was tempted to modifycoerceOutput (which I did) and some test (59 😅 ) failed. AFAIK, coerceOutput will make sure that the right value is returned to the client, so probably that change didn’t make any sense.

Is there anything we missing? If you think this is a bug, if you could provide any hint to where to look, we will more than happy to provide a patch.

cc:/ @BjRo

[Axxiss]

Thanks a lot @OlegIlyenko for taking a look so quickly. 😄

Yes, types are there and contains the right information. This is the output:

[info] FOO = foo_value
[info] BAR = bar_value

We’ll try to come up with a test case for this.

[Axxiss]

Thanks for the hint Oleg!

Extending RawResultMarshaller and doing the conversion to Json there seems to be working. Thanks again for the detailed answers and the support provided 😃