The base images strive to provide the same environment that AWS provides to Lambda functions. This page describes it and any incompatibilities between AWS Lambda and Dockerized Lambda.
IronFunctions has sync/async communication with Request/Response workflows.
- sync: returns the result as the body of the response
- async: returns the task id in the body of the response as a json
The context.succeed()
will not do anything with result
on node.js, nor will returning anything from a Python function.
We do not make any compatibility efforts towards running your lambda function in the same working directory as it would run on AWS. If your function makes such assumptions, please rewrite it.
- node.js version 0.10.42
- ImageMagick version 6.9.3 and nodejs wrapper 6.9.3
- aws-sdk version 2.2.12
Payloads MUST be a valid JSON object literal.
- context.fail() does not currently truncate error logs.
context.functionName
is of the form of a docker image, for exampleiron/test-function
.context.functionVersion
is always the string"$LATEST"
.context.invokedFunctionArn
is not supported. Value is empty string.context.memoryLimitInMB
does not reflect reality. Value is always256
.context.awsRequestId
reflects the environment variableTASK_ID
. On local runs fromironcli
this is a UUID. On IronFunctions this is the task ID.logGroupName
andlogStreamName
are empty strings.identity
andclientContext
are alwaysnull
.
If your handler throws an exception, we only log the error message. There is no
v8::CallSite
compatible stack trace yet.
Event is always a __dict__
and the payload MUST be a valid JSON object
literal.
context.functionName
is of the form of a docker image, for exampleiron/test-function
.context.functionVersion
is always the string"$LATEST"
.context.invokedFunctionArn
isNone
.context.awsRequestId
reflects the environment variableTASK_ID
which is set to the task ID on IronFunctions. If TASK_ID is empty, a new UUID is used.logGroupName
,logStreamName
,identity
andclientContext
areNone
.
If your Lambda function throws an Exception, it will not currently be logged as a JSON object with trace information.
- OpenJDK Java Runtime 1.8.0
The Java8 runtime is significantly lacking at this piont and we do not recommend using it.
There are some restrictions on the handler types supported.
Since Lambda does not support request/response invocation, we explicitly prohibit a non-void return type on the handler.
AWS uses the Jackson parser, this project uses the GSON parser. So JSON parse errors will have different traces.
Given a list handler like:
public static void myHandler(List<Double> l) {
// ...
}
If the payload is a single number, AWS Lambda will succeed and pass the handler a list with a single item. This project will raise an exception.
This project cannot currently deserialize a List or Map containing POJOs. For example:
public class Handler {
public static MyPOJO {
private String attribute;
public void setAttribute(String a) {
attribute = a;
}
public String getAttribute() {
return attribute;
}
}
public static void myHandler(List<MyPOJO> l) {
// ...
}
}
This handler invoked with the below event will fail!
[{ "attribute": "value 1"}, { "attribute": "value 2" }]
Using the types in aws-lambda-java-core
to implement handlers is
untested and unsupported right now. While the package is available in your
function, we have not tried it out.
The log4j and LambdaLogger styles that log to CloudWatch are not supported.
context.getFunctionName()
returns a String of the form of a docker image, for exampleiron/test-function
.context.getFunctionVersion()
is always the string"$LATEST"
.context.getAwsRequestId()
reflects the environment variableTASK_ID
which is set to the task ID on IronFunctions. If TASK_ID is empty, a new UUID is used.getInvokedFunctionArn()
,getLogGroupName()
,getLogStreamName()
,getIdentity()
,getClientContext()
,getLogger()
returnnull
.