LambdaRestApi doesn't add the handler when .withOptions is used

[leepa]

If I do this - I end up with the Lambda Handler not added to the {proxy+} and instead it points to MOCK

        LambdaRestApi edgeApi = new LambdaRestApi(this, "ShopBackendEdge", LambdaRestApiProps.builder()
                .withOptions(RestApiProps.builder()
                        .withRestApiName("TroutApiEdge")
                        .withDescription("Artifishial Intelligence ordering API @ Edge")
                        .build())
                .withProxyPath("/")
                .withHandler(dummyLambda)
                .build());

If I remove the .withOptions, then handler is correctly added and the API works.

[mbulman]

+1. Just discovered this an almost filed a dupe.

I think this can be traced to the constructor for LambdaRestApi where it's merging the defaultIntegration property passed in with the RestApiProps object passed into withOptions. RestApiProps extends ResourceBase which has the defaultIntegration property as well. I suspect the RestApiProps.Builder is returning a null defaultIntegration rather than not returning that key at all, which blows away the defaultIntegration explicitly set in LambdaRestApi

https://github.com/awslabs/aws-cdk/blob/707f02c3c9de58e84d5342b7f684207fcb50c8bf/packages/%40aws-cdk/aws-apigateway/lib/lambda-api.ts#L50

[rix0rrr]

Oh man, that should be a jsii compliance test!

[eladb]

On it

[eladb]

Oh JavaScript. TIL:

console.log({
  ...{
    hello: 'hello'
  },
  ...{
    hello: undefined
  }
});

Returns:

{ hello: undefined }

Which was not what I expected, and will make it harder to solve this.

[eladb]

The current behavior of the Java bindings is that data types (created through the generated builders) are basically normal classes that implement the jsii interface and when passed to the js code they are passed by reference and not serialized into a JSON object.

This means that when the JS code wants to read a property value (i.e. hello in the above example), it will call back to the Java code and the Java code will invoke getHello() on the PoJo, which will return null (in case the property was not specified). Even if the null is converted to undefined, it doesn't matter because the JS object has a key named hello and it will override when used like above.

[mbulman]

Sounds like an interesting general problem to solve, but for this case specifically would simply flipping order solve the issue?

Going from:

super(scope, id, {
      defaultIntegration: new LambdaIntegration(props.handler),
      ...props.options
    });

to

super(scope, id, {
      ...props.options,
      defaultIntegration: new LambdaIntegration(props.handler)
    });

props.handler is required and props.options.defaultIntegration is specifically forbidden.

[eladb]

Ideally we want to solve this at the right layer (i.e. jsii) so that user code (i.e. CDK) will not have to be aware of these cross-language quirks.

[mbulman]

Understood. But there is nothing intrinsically right or wrong about either ordering above (i.e. changing it does not make the code better or worse), so if the ideal fix is significant effort+time it would be nice to consider a short term solution for this particular case.

[eladb]

Hopefully we will be able to fix it at the source: aws/jsii#376

[mbulman]

👍