script.r and script.R appear to be case sensitive and differ by region

[DaveParr]

Thanks for the ground work. This is really exciting.

In working through the examples I believe I've found an 'undocumented inconsitency':

I can run the listed examples perfectly.

I then attempted to 'translate' your shell scripts to support region eu-west-2

1. I use your template to check for the most recent publishing of R v3.6.0

aws lambda list-layer-versions --max-items 1 --no-paginate  \
    --layer-name arn:aws:lambda:eu-west-2:131329294410:layer:r-runtime-3_6_0 \
    --query 'LayerVersions[0].LayerVersionArn' --output text

Which returns arn:aws:lambda:eu-west-2:131329294410:layer:r-runtime-3_6_0:4

2. I create a new function where I supply the above, modifying the :

chmod 755 script.r

zip function.zip script.r

aws lambda create-function --function-name r-example \
--zip-file fileb://function.zip --handler script.increment \
--runtime provided --timeout 60 \
--layers arn:aws:lambda:eu-west-2:131329294410:layer:r-runtime-3_6_0:4 \
--role <my-role-arn> --region eu-west-2

This returned 200, and function is created in eu-west-2, crucially I have used the identical script.r (lower case)

3. Attempting to invoke the new version

aws lambda invoke --function-name r-example \
    --payload '{"x":1}' --region eu-west-2 response.txt      
cat response.txt

return:

{
    "StatusCode": 200,
    "FunctionError": "Unhandled",
    "ExecutedVersion": "$LATEST"
}

Checking in the web console I see this in cloud watch:

2019-05-31 14:55:25 INFO::Sourcing 'script.R'
Error in file(filename, "r", encoding = encoding) : 
cannot open the connection
Calls: source -> file
In addition: Warning message:
In file(filename, "r", encoding = encoding) :
cannot open file 'script.R': No such file or directory
Execution halted

4. I open the lambda in console, and manually rename the script.r (lower) to script.R (upper)

5. I reinvoke as step 2 with success

{
    "StatusCode": 200,
    "ExecutedVersion": "$LATEST"
}
cat response.txt
{"result":2}

Is this an accidental side effect from the differing r-runtime layers? How can I workout which needs what? should there be a uniform treatment?

Thanks again for the work 😄

[philipp94831]

Hi @DaveParr, in agreement with #7, only .R is accepted as a valid file extension. The runtime should be the same in any region. In the first versions of this project, .r was a valid extension. Can you please check which version you used with .r?

[DaveParr]

I followed the blog here: https://medium.com/bakdata/running-r-on-aws-lambda-9d40643551a6 Specifically using the R layer with the arn: arn:aws:lambda:eu-central-1:131329294410:layer:r-runtime:10

[philipp94831]

Hi @DaveParr, the version in the blog post is very old and indeed was only able to handle .r extensions. I will add support for .r as a fallback extension and also consider updating the blog post. Thanks for the feedback!

[DaveParr]

IMHO, just updating the blog post with a statement saying '.r is old, .R is new and will continue to be used instead' would be sufficient, and maybe adding a 'Changelog' section to the Read.me. From #7 it's obvious that a consistent (and correct) decision has been made. It's just a little hidden and obviously tripped me up in the transition between example and practice.

Thanks again for all the ground-work. Invaluable. 👍

[philipp94831]

Hi @DaveParr, from now on, both .r and .R are supported. I think that should be the best solution. I will start maintaining a changelog in the future to avoid confusion :)