Ok; we have our ducks in a row, so let’s fire off the test event from the CLI and see what happens (it probably goes without saying at this point, but make sure all your AWS objects are consistent with regards to zone. Here, we use us-east-1):
$ aws lambda invoke --invocation-type Event --function-name CreateThumbnail --region us-east-1 --payload file://input.txt
If you’ve read through the AWS notes, particularly the code, you know that after trigger and execution, we should receive an image in the output bucket that has been scaled in size, to a thumbnail, a very common task. A quick inspection of the output bucket after these steps revealed nada; the process failed. Thankfully, one can take advantage of another great feature of the AWS suite, cloudwatch logs. Here’s a screen grab of what I saw, when selecting a recent log for the CreateThumbnail function :
A little cryptic, but I deduce after a quick check that I managed to introduce an extra directory level into the uploaded zipfile, despite copious warnings within several AWS Lambda examples to avoid this. Therefore the runtime failed to find the function handler where it expected it to be. I re-zip the code and dependencies, upload, re-trigger from the CLI and see the following pop up in the cloud watch log:
Success!! A glance at the output S3 bucket confirms that the thumbnail image was produced correctly. Time for a celebratory coffee. All this data moving around has me thinking I should invest a little more in compression. I wonder if Pied Piper’s platform is ready yet?