Exception de-serializing errors sent by AWS AppSync

[vladdex]

Issue Description

Some errors sent by an application built on AWS AppSync contain and extra field called "data" which does exist in the GraphQLError class.
Furthermore if I ignore unknown properties the GraphQLErrorType is missing error types provided by AppSync ex Lambda:Unhandled.
Is there any way to override these when generating the models ?

Steps to Reproduce

To reproduce try to de-serialize the following json into a GraphQLResult

{
    "data": null,
    "errors": [
        {
            "path": [
                "addProject"
            ],
            "data": null,
            "errorType": "Lambda:Unhandled",
            "errorInfo": null,
            "locations": [
                {
                    "line": 1,
                    "column": 23,
                    "sourceName": null
                }
            ],
            "message": "There is already a Project with name AutoProj-Duplicate1679598192925 in the system"
        }
    ]
}

Expected Result

Json should de-serialize correctly

Actual Result

De-serialization fails because "data" is an urecognised field and Lambda:Unhandled is an unrecognised error type

Your Environment and Setup

• graphql-java-codegen version: 5.6.0
• Build tool: Gradle

[kobylynskyi]

@vladdex so there are 2 issues:
1 - Unknown field in the response is handled solely on your side by ignoring unknown properties. There's nothing to do with this library/plugin.
2 - Unknown ErrorType - I agree that this needs to be fixed in this graphql-java-codegen plugin itself because different servers that are adopting graphql spec might have different error types. So I think the solution this case would be to change errorType field in GraphQLError class from GraphQLErrorType errorType to String errorType. This would become a breaking change and I would need to include this fix into a next major version 6.0.0. Until this is done, I suggest you to use READ_UNKNOWN_ENUM_VALUES_AS_NULL in your Jackson configuration.

[vladdex]

@kobylynskyi

1. I agree, ignoring unknown fields did the trick.
2. Reading unknown enums as null did the trick as well.

For issue 1 I'm thinking if it would be possible to add a functionality that lets you add specific fields to certain predefined classes during code generation, remap that class to a custom one. While ignoring that field in this case is ok, because it's null, there might be cases where valuable data might be there.

Thanks,
Vlad