Lambda error handling

[asafshen]

Hey 👋

I'm relatively new to the AWS ecosystem, so please bear with my questions.

Context

I'm writing a Lambda function using Node.js 18.x and invoking the function from a Golang application.

Lambda code:

// index.mjs 

export const handler = async (event) => {
    // Do some stuff and 
    if (...) {
        throw new Error('Oops');
    }
    return { a: 'b' };
}

Golang code

input := &lambda.InvokeInput{
		FunctionName: aws.String("MyFunc"),
		Payload:      []byte(`{}`),
	}
res, err := lambdaClient.Invoke(input)
if err != nil {
    return err
}
// do something with with res.Payload

The problem I'm facing

When the Lambda code fails, e.g., throws an unhandled exception, I don't receive an err. However, I do:

1. Check if res.FunctionError is not nil (which, from my experience, indicates Unhandled in this case).
2. If it's not nil, unmarshal the payload into the following struct:

type LambdaErrorPayload struct {
	ErrorMessage string   `json:"errorMessage"`
	ErrorType    string   `json:"errorType"`
	StackTrace   []string `json:"stackTrace"`
}

Although I understand that the SDK API makes sense here because the Lambda execution succeeds (just with an exception), I find it confusing. I expect the abstraction layer above this to behave differently, especially in Go, where you would anticipate a function to return an error if it fails.

Proposed Solution

A few things that I can think of:

1. Return an error in this case (though I understand it's not backward-compatible).
2. Provide structs and functionality to convert Lambda output to the error struct described above.

Questions

• Are there any gaps in my mental model of the execution?
• What is the best practice in terms of functional error handling?
• What do others think?

[RanVaknin]

Hi @asafshen ,

Thanks for posting the question and sorry about the slow response time.

You have understood correctly how the Invoke lambda response works. A successful invocation would mean that the Lambda executed successfully, regardless of what you send back from that lambda itself whether it be an error or an exception.

I expect the abstraction layer above this to behave differently, especially in Go, where you would anticipate a function to return an error if it fails.

I understand the confusion, however err will only get populated if the Lambda API server fails to invoke your function.
In other words, errors on lambda are application level errors, whereas errors thrown in the SDK are infrastructure level errors.

• Are there any gaps in my mental model of the execution?
• What is the best practice in terms of functional error handling?

I think your error handling assumption is good. You can follow this Node.js AWS Lambda error handling doc for more info about error handling from a lambda context.

Let me know if you have any questions,

Thanks,
Ran~

[github-actions[bot]]

Hello! Reopening this discussion to make it searchable.