Issue with Decorated Object Returning Null instead of resolving wrapped

[florianajir]

Q	A
Bug report?	yes
Feature request?	no
BC Break report?	no
RFC?	no
Version/Branch	0.15.2

I'm encountering a bug related to a decorated object and I'm unsure if this is a known limitation or a mistake on my part. I'm using the bundle in a Symfony app.

My objective is to create a given structure for my response, so I decided to decorate my entity Order (object) with a NodePermission (object), which declare a field authorization (object) that contains computed data via resolver. However, I'm facing an issue where the authorization field, returns null instead of instantiating it with resolved fields.

Here's the relevant code for reference:

Configuration

config/graphql/order/types/Order.types.yaml

Order:
    type: object
    inherits: [NodePermission]
    config:
        fields:
            id:
                type: "Int!"

config/graphql/common/decorator/NodePermission.yaml

NodePermission:
    type: 'object'
    decorator: true
    config:
        interfaces: ["NodePermissionInterface"]
        fields:
            authorization: 
                type: 'Authorization' # returns null in response
                description: 'The authorization for a user to perform an action on an object or on a set of object properties.'

config/graphql/common/interface/NodePermissionInterface.yaml

NodePermissionInterface:
    type: "interface"
    config:
        fields:
            authorization:
                type: 'Authorization'

config/graphql/common/types/Authorization.types.yaml

Authorization:
    type: object
    config:
        fields:
            test:
                type: "Boolean!"
                resolve: '@=query("test", value)' # returns true

Response

actual

{
  "data": {
    "getOrder": {
      "id": "1",
      "authorization": null
    }
  }
}

expected

{
  "data": {
    "getOrder": {
      "id": "1",
      "authorization": {
        "test": true
      }
    }
  }
}

I believe this is a common usage scenario, so I would be surprised if it's not a supported feature.

[Vincz]

Hi @florianajir! Did you managed to fix your problem?

[florianajir]

Workaround found using a resolver instantiating a Data-value object