Is this working?

Hello,

I tried to use cargo-lambda-cdk to build a lambda function with API Gateway in front of it. But i was not successful. The build and deployment worked, but you received the following error when executing the function. I am using local builds (no docker since those fail building) on macOS with an M1

Error: Couldn't find valid bootstrap(s): [/var/task/bootstrap /opt/bootstrap]
Runtime.InvalidEntrypoint

When comparing the created lambda function with another function I have, I found the difference that the cargo-lambda-cdk creates a nested structure which leads to the error.

working structure

cargo lambda structure

I managed to deploy the example i ll dig and find to see what the difference is and share here.

Found the issue the package-name (second parameter) in the cdk construct RustFunction needs to be equivalent to the package name in the Cargo.toml otherwise the cdk.out will create a nested folder in the assethash.
Wow...

Literally just ran into this. Felt like I was going crazy

Thanks for opening this issue. We might be able to improve that, I'll take a look.

I just ran into this and here is what I found:

Given a Rust function with package name rust-function in Cargo.toml this deployment works:

new RustFunction(this, "rust-function", {
      manifestPath: path.join(__dirname, "..", "..", "rust-function")
    });

The next one doesn't but in a rather surprising way: bundling works, but the bootstrap binary is in a subpath of the generated asset folder called rust-function:

new RustFunction(this, "some-package-name", {
      manifestPath: path.join(__dirname, "..", "..", "rust-function")
    });

The user only "sees" the problem after deployment when calling the lambda function and getting the error mentioned above:

Error: Couldn't find valid bootstrap(s): [/var/task/bootstrap /opt/bootstrap]
Runtime.InvalidEntrypoint

But: this configuration also works:

new RustFunction(this, "some-cdk-id-that-has-nothing-to-do-with-the-package-name", {
      binaryName: "rust-function",
      manifestPath: path.join(__dirname, "..", "..", "rust-function")
    });

It also has the advantage that bundling fails if the given binary name does not exist and that the second parameter can be used as usual in cdk contexts: for the construct id and not as a hidden parameter for bundling. The error with an invalid binaryName looks like this:

Error: Failed to bundle asset <project>/<some-cdk-id-that-has-nothing-to-do-with-the-package-name>/Code/Stage, bundle output is located at <some path>/cdk.out/bundling-temp-<hash>-error: Error: bash exited with status 1

In order to prevent other users from running into this problem the binaryName prop could be marked as non-optional which would be a breaking change but because this package is at version 0.0.14 I guess it would be ok?

What do you think?

Note: I didn't check if this works for extensions. I guess the relevant code path for binaries is here:

cargo-lambda-cdk/src/bundling.ts

Lines 182 to 194 in 27c61cd

    
           let flattenPackage = props.packageName; 
        
           if (props.binaryName) { 
        
             buildBinary.push('--bin'); 
        
             buildBinary.push(props.binaryName); 
        
             flattenPackage = props.binaryName; 
        
           } 
        
           if (!props.lambdaExtension && flattenPackage) { 
        
             buildBinary.push('--flatten'); 
        
             buildBinary.push(flattenPackage); 
        
           }

The CDK construct name should not be directly tied to the binary name. Tying the two together is just a foot gun.

The most preferable solution to me would be to just read the cargo.toml file and infer the binary name from the config. That way the binaryName prop could be left optional.

A quick and dirty way of making it required would still be an improvement.

The most preferable solution to me would be to just read the cargo.toml file and infer the binary name from the config. That way the binaryName prop could be left optional.

This makes sense to me. Feel free to open a PR with changes. I very welcome contributions to make this software better.

Sounds good. I'll try and put one through tomorrow.

I've implemented package auto-detection in #21. Please, open a new issue if you find any other problems with this project. Closed issues are very hard to track.

	let flattenPackage = props.packageName;

	if (props.binaryName) {
	buildBinary.push('--bin');
	buildBinary.push(props.binaryName);
	flattenPackage = props.binaryName;
	}

	if (!props.lambdaExtension && flattenPackage) {
	buildBinary.push('--flatten');
	buildBinary.push(flattenPackage);
	}