Aws-cdk: Python jsii: trying to serialize a function (after forgetting to call it) yields a very obscure error message

[swapnil-jak]

:bug: Bug Report

What is the problem?

I'm using the AWS CDK with Python. I'm trying to add an Ingress Rule to a VPC SecurityGroup using the add_ingress_rule() method within the aws_ec2.SecurityGroup construct. The method signature is as described in the API documentation here

However, when I run cdk deploy the following error is thrown : AttributeError: 'method' object has no attribute '__jsii__type__'

It seems CDK doesn't like the connection = ec2.Port.tcp(443) parameter.

Reproduction Steps

Simple Code as below -

`
#!/usr/bin/env python3

from aws_cdk import (
    core,
    aws_ec2 as ec2
)

my_env = {
    'region': 'eu-west-1'
}

class NetworkStack(core.Stack):

    def __init__(self, scope:core.Construct, id:str, **kwargs):
        super().__init__(scope, id, **kwargs)

        ## VPC
        vpc = ec2.Vpc(
            self,
            id="vpc",
            cidr="192.169.0.0/16",
            max_azs = 2,
            nat_gateways = 1,
            subnet_configuration=[
                ec2.SubnetConfiguration(name = 'Web', subnet_type = ec2.SubnetType.PUBLIC, cidr_mask=20),
                ec2.SubnetConfiguration(name = 'App', subnet_type = ec2.SubnetType.PRIVATE, cidr_mask=20),
                ec2.SubnetConfiguration(name = 'Data', subnet_type = ec2.SubnetType.PRIVATE, cidr_mask=20)
            ]
        )

        sg_elb = ec2.SecurityGroup(
            self,
            id = "sg_elb",
            vpc = vpc,
            security_group_name = "sg_elb"
        )
        # PROBLEM !!    
        sg_elb.add_ingress_rule(
            peer = ec2.Peer.any_ipv4,
            connection = ec2.Port.tcp(443)
        )

app = core.App()
NetworkStack(app, "cdk-scratch", env=my_env)

app.synth()

`

Verbose Log

$ cdk deploy cdk-scratch --profile blaze-projects Traceback (most recent call last): File "app.py", line 54, in <module> NetworkStack(app, "cdk-scratch", env=my_env) File "D:\blazeclan-git-repo\aws-cdk-stuff\cdk-scratch\.env\lib\site-packages\jsii\_runtime.py", line 66, in __call__ inst = super().__call__(*args, **kwargs) File "app.py", line 50, in __init__ connection = ec2.Port.tcp(443) File "D:\blazeclan-git-repo\aws-cdk-stuff\cdk-scratch\.env\lib\site-packages\aws_cdk\aws_ec2\__init__.py", line 19275, in add_ingress_rule return jsii.invoke(self, "addIngressRule", [peer, connection, description, remote_rule]) File "D:\blazeclan-git-repo\aws-cdk-stuff\cdk-scratch\.env\lib\site-packages\jsii\_kernel\__init__.py", line 104, in wrapped return _recursize_dereference(kernel, fn(kernel, *args, **kwargs)) File "D:\blazeclan-git-repo\aws-cdk-stuff\cdk-scratch\.env\lib\site-packages\jsii\_kernel\__init__.py", line 267, in invoke args=_make_reference_for_native(self, args), File "D:\blazeclan-git-repo\aws-cdk-stuff\cdk-scratch\.env\lib\site-packages\jsii\_kernel\__init__.py", line 119, in _make_reference_for_native return [_make_reference_for_native(kernel, i) for i in d] File "D:\blazeclan-git-repo\aws-cdk-stuff\cdk-scratch\.env\lib\site-packages\jsii\_kernel\__init__.py", line 119, in <listcomp> return [_make_reference_for_native(kernel, i) for i in d] File "D:\blazeclan-git-repo\aws-cdk-stuff\cdk-scratch\.env\lib\site-packages\jsii\_kernel\__init__.py", line 130, in _make_reference_for_native d.__jsii__type__ = "Object" AttributeError: 'method' object has no attribute '__jsii__type__' Subprocess exited with error 1 (.env)

Environment

• CDK CLI Version: 1.8.0 (build 5244f97)
• Module Version: aws-cdk.aws-ec2 Version 1.8.0
• OS: Windows 10
• Language: Python 3.7.2

Other information

[jsmith97]

Having exactly the same issue as detailed above, I fixed it with the following syntax..

 bastion_sg.add_ingress_rule(
            peer=ec2.Peer.any_ipv4(),
            connection=ec2.Port.tcp(22),
            description='allow ssh from anywhere to bastion server'
        )

[rix0rrr]

Oh, I see. The difference is in peer=ec2.Peer.any_ipv4 vs peer=ec2.Peer.any_ipv4().

Thanks for posting @jsmith97, I completely missed that first time scanning over the code.

Seems that JSII could supply a better error message here.