bug: Custom scalar does not deserialize correctly with 4.6.0

[kmccarp]

We have a type defined like this:

input FooInput {
    bars: [BarInput!]
}

input BarInput {
    name: String!
    value: Object!
}

scalar Object

scalar Object is defined as follows:

@DgsComponent
public class ObjectScalar {

    @DgsRuntimeWiring
    public RuntimeWiring.Builder addScalar(RuntimeWiring.Builder builder) {
        return builder.scalar(ExtendedScalars.Object);
    }
}

Expected behavior

When calling a mutation with FooInput as input, I expect it to deserialize bars as List<BarInput>.

Actual behavior

When calling a mutation with FooInput as input, it deserializes bars as List<LinkedHashMap> instead of List<BarInput>.

Steps to reproduce

1. Create types as defined in summary
2. Create a mutation that takes FooInput as input
3. Generate graphql types as necessary
4. Use a graphql client to call your mutation
5. See that BarInput is deserialized to LinkedHashMap (i.e. not successfully deserialized to BarInput)

Might be related to (or fixed by?) this: #344

[paulbakker]

My guess is that you forgot to use the collectionType argument which is described here.

The related change in 4.6.0 is this: #549. Prior to this change, some code that was incorrect was accidentally "working" because of the extra conversion Jackson was doing.
Can you try using @InputArgument(collectionType = BarInput.class) to confirm that works correctly?

I've added a test specifically for the Object scalar, but that seems to work fine and is probably unrelated to the issue you're seeing. #589.

[paulbakker]

Closing this as invalid, based on the test I've added (see comment above). Please re-open if that turns out to be incorrect.

[nsnichols]

The test scenario doesn't handle complex input objects with nested lists. If your top level object is not a list, but it contains a list, the objects in the list don't get converted to the correct types. They remain maps and then any logic that uses the values in the list blow up with a class cast exception.

I see this issue when there are no custom scalars involved.

input Complex {
    something: String!
    list: [InList!]!
}

input InList {
    field1: String!
    field2: String!
}

type Out {
    value: String!
}

type Mutation {
    complex(arg: Complex!): Out!
 }

    @DgsComponent
    public static class Mutation {
        @DgsMutation(field = DgsConstants.MUTATION.Complex)
        public Out executeMutation(@InputArgument("arg") Complex complex) {
            // Blows up on the next line
            var first = complex.getList().get(0);
            return new Out("whatever");
        }
    }

[paulbakker]

Thanks for the additional context, let me look into it further.

[kmccarp]

To add to @nsnichols 's comment, if you had two list types, collectionType cannot be specified for both:

input FooInput {
    bars: [BarInput!]
    bazs: [BazInput!]
}

input BarInput {
    name: String!
    value: Object!
}

input BazInput {
  id: String!
  value: String!
}

scalar Object

[paulbakker]

Thanks for clarifying the issue - I was obviously looking at the wrong thing and this bug was a huge oversight.
And yes, collectionType was clearly not the right answer here.

Anyway, I think I have a fix for the issue. It's more reflection magic, so we'll need to do some more testing, but it looks promising.

The fix is in #591

[paulbakker]

Fix is released in 4.7.0. Hopefully for real this time!