"bad deno executable" after pre-handler error

[kyeotic]

The boostrap investigate function seems to handle pre-handler error's badly. I had uncaught exception during setup, and this showed up in the logs afterwards.

2020-11-17T13:27:33.673-08:00Copy�[0m�[1m�[31merror�[0m: Could not create TypeScript compiler cache location: "/home/sbx_user1051/.cache/deno/gen" | �[0m�[1m�[31merror�[0m: Could not create TypeScript compiler cache location: "/home/sbx_user1051/.cache/deno/gen"
-- | --
  | 2020-11-17T13:27:33.673-08:00 | Check the permission of the directory.
  | 2020-11-17T13:27:33.674-08:00 | error: bad deno executable

After fixing the error the lambda ran fine, so I don't think the deno executable is actually bad.

[hayd]

Are you running the executable locally?

Generally that won't work, AWS Lambda runs Amazon Linux 1 which requires a compatible binary (that isn't compatible with many linux distros). You can test using docker-lambda.

Or am I misunderstanding the issue? How are you getting this?

[kyeotic]

Those logs came from cloudwatch, using the 1.4.3 deno-lambda-layer zip from the releases page.

[hayd]

I think I understand the issue.

It seems like the layer must be used as a layer, rather than as a function (I didn't think this was a requirement but perhaps it is now?). I am going to update the bootstrap to error properly:

deno executable not found in PATH

Will be fixed in #115 (see diff from bootstrap)

[hayd]

So, it's actually that deno eval that tries to create the directory... which is surprising.

Fixed in al2 PR: 789e625

[revgum]

Thank you very much for deno-lambda, it's really great!

I just wanted to add some details of things I found this morning as I was digging into a rough edge I bumped into.

I was getting this error bad deno executable along with some other errors in a couple of situations;

• When the data payload to be returned exceeded the memorySize configured for the Lambda
• When the response time exceeded the default 6 second configuration for Lambda
• and then after configuring the Lambda timeout; when the response time exceeded the 30 second configuration for APIGateway
• When I hadn't set DENO_FLAGS to allow writing (reverted to leaving it as default -A instead)

For other API calls that were designed to be faster (<30sec), everything is working fine.

Here's one scenario example of Cloudwatch logs with more context;

Check file:///tmp/runtime.js
--
DynamoDb client configured to us-west-2 region.

START RequestId: 6ea516e3-d7ec-4a81-85bd-12b21e787097 Version: $LATEST

memory allocation of 111809360 bytes failed

/opt/bootstrap: line 237:    27 Aborted                 (core dumped) DENO_DIR=/tmp/deno_dir DENO_PREFIX=$DENO_PREFIX DENO_FLAGS=$DENO_FLAGS NO_COLOR=true deno run $DENO_FLAGS /tmp/runtime.js
�[0m�[1m�[31merror�[0m: Could not create TypeScript compiler cache location: "/home/sbx_user1051/.cache/deno/gen"
Check the permission of the directory.

error: bad deno executable

Unexpected bootstrap error when calling AWS_LAMBDA_RUNTIME_API /init/error: {     "errorMessage": "State transition from Ready to InitError failed for runtime. Error: State transition is not allowed",     "errorType": "InvalidStateTransition" }

END RequestId: 6ea516e3-d7ec-4a81-85bd-12b21e787097

REPORT RequestId: 6ea516e3-d7ec-4a81-85bd-12b21e787097	Duration: 8612.69 ms	Billed Duration: 8613 ms	Memory Size: 256 MB	Max Memory Used: 256 MB
 ```

[hayd]

Sorry I should've cherry-picked the fix for 1.6.0, that error message is a red herring!

Hopefully we can get al2 in before 1.6.1, otherwise ensure the bootstrap fix make their way in to 1.6.1 anyhow.