Skip to content

unsupported type error for supported type #90

Description

@richardhboyd

I have an entry in my schema that looks like this:

        "EBSVolumeSize": {
            "description": "The size for the underlying EBS Volume.",
            "type": "integer",
            "minimum": 10,
            "maximum": 250
        },

here is the generated ResourceModel:

@dataclass
class ResourceModel(BaseModel):
    InstanceId: Optional[str]
    Name: Optional[str]
    InstanceType: Optional[str]
    Description: Optional[str]
    EBSVolumeSize: Optional[int]
    UserData: Optional[str]

And my CFN Template looks like such:

AWSTemplateFormatVersion: 2010-09-09
Resources:
  MyC9Environment02:
    Type: Richard::Cloud9::Environment
    Properties:
      InstanceType: c5.large
      EBSVolumeSize: 50

But during my Resource Provider Execution (in the CFN Service, not locally) get the following error:

Invalid request
Traceback (most recent call last):
  File "/var/task/cloudformation_cli_python_lib/resource.py", line 206, in _cast_resource_request
    ).to_modelled(self._model_cls)
  File "/var/task/cloudformation_cli_python_lib/utils.py", line 123, in to_modelled
    desiredResourceState=model_cls._deserialize(self.desiredResourceState),
  File "/var/task/richard_cloud9_environment/models.py", line 57, in _deserialize
    recast_object(cls, json_data, dataclasses)
  File "/var/task/cloudformation_cli_python_lib/recast.py", line 29, in recast_object
    raise InvalidRequest(f"Unsupported type: {type(v)} for {k}")
cloudformation_cli_python_lib.exceptions.InvalidRequest: Unsupported type: <class 'int'> for EBSVolumeSize
Handler error
Traceback (most recent call last):
  File "/var/task/cloudformation_cli_python_lib/resource.py", line 206, in _cast_resource_request
    ).to_modelled(self._model_cls)
  File "/var/task/cloudformation_cli_python_lib/utils.py", line 123, in to_modelled
    desiredResourceState=model_cls._deserialize(self.desiredResourceState),
  File "/var/task/richard_cloud9_environment/models.py", line 57, in _deserialize
    recast_object(cls, json_data, dataclasses)
  File "/var/task/cloudformation_cli_python_lib/recast.py", line 29, in recast_object
    raise InvalidRequest(f"Unsupported type: {type(v)} for {k}")
cloudformation_cli_python_lib.exceptions.InvalidRequest: Unsupported type: <class 'int'> for EBSVolumeSize

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/var/task/cloudformation_cli_python_lib/resource.py", line 231, in __call__
    request = self._cast_resource_request(event)
  File "/var/task/cloudformation_cli_python_lib/resource.py", line 209, in _cast_resource_request
    raise InvalidRequest(f"{e} ({type(e).__name__})") from e
cloudformation_cli_python_lib.exceptions.InvalidRequest: Unsupported type: <class 'int'> for EBSVolumeSize (InvalidRequest)

I haven't written any code to handle the EBSVolume property so I'm not sure why this is being thrown. It always seems to happen about 2-3min after the provisioning starts.

Activity

  1. richardhboyd commented on Apr 25, 2020

    @richardhboyd
    ContributorAuthor

    Sending it in as a string in cfn invoke ... has it echo back out as an int

    {
      "credentials": "<redacted>",
      "action": "CREATE",
      "request": {
        "clientRequestToken": "54083fde-95d5-4618-a4b1-f8d706c306f7",
        "desiredResourceState": {
          "InstanceType": "t2.micro",
          "EBSVolumeSize": "50"
        }
      },
      "callbackContext": null
    }
    === Handler response ===
    {
      "status": "IN_PROGRESS",
      "message": "",
      "callbackContext": {
        "ENVIRONMENT_ID": "412fa1aeaa6241b3af94561121c6d7ee",
        "LOCAL_STATUS": "ENVIRONMENT_CREATED"
      },
      "callbackDelaySeconds": 15,
      "resourceModel": {
        "InstanceType": "t2.micro",
        "EBSVolumeSize": 50
      }
    }

    Sending it in as an int throws the same error

  2. richardhboyd commented on Apr 26, 2020

    @richardhboyd
    ContributorAuthor

    Current hypothesis is that it happens when the service-side lambda times out and the latest model returned by the resource provider can't be properly deserialized when the function is re-invoked.

  3. added a commit that references this issue on Apr 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions