Match error handling to other runtimes

[rimutaka]

The format of error messages returned by the runtime is hard to work with at the client end.

Example:

{
  "errorType": "alloc::boxed::Box<dyn std::error::Error+core::marker::Sync+core::marker::Send>",
  "errorMessage": "LambdaError { msg: \"cust error\", source: \"somewhere in code\", code: InvalidInput }"
}

It is produced by this code in

aws-lambda-rust-runtime/lambda/src/lib.rs

Line 216 in f404617

Err(e) => EventErrorRequest {

Err(e) => EventErrorRequest {
                request_id,
                diagnostic: Diagnostic {
                    error_message: format!("{:?}", e),
                    error_type: type_name_of_val(e).to_owned(),
                },
            }
            .into_req()?,

with help from

fn type_name_of_val<T>(_: T) -> &'static str {
    std::any::type_name::<T>()
}

Proposed change

1. Log the error message, probably via error! so that it appears in CloudWatch.
2. Serialise e into JSON instead of Debug output ({:?}).
3. Allow to set error type and fall back on std::any::type_name if none was provided.

Here are examples of what other runtimes are producing:

• C#: https://docs.aws.amazon.com/lambda/latest/dg/csharp-exceptions.html
• Go: https://docs.aws.amazon.com/lambda/latest/dg/golang-exceptions.html
• Java: https://docs.aws.amazon.com/lambda/latest/dg/java-exceptions.html
• NodeJS: https://docs.aws.amazon.com/lambda/latest/dg/nodejs-exceptions.html

Discussion

I'm not 100% sure how it all can be implemented yet. Just wondering if this is a problem that impacts others and is worth looking into.

[softprops]

Serialise e into JSON instead of Debug output ({:?}).

I have an even simpler suggestion, use Display instead of Debug. Display is often implemented precisely for displaying a message. Debug is not meant for this purpose. You get this for free as implementing Error requires it so no extra type constraints are needed .

[softprops]

Allow to set error type and fall back on std::any::type_name if none was provided.

We had a similar set up in the past but required muuuch more machinery and was a bit onerous on the user end. There might still.be a way to have the best of both worlds with fancy downcasting. I'd propose some unit tests here. Might have caught the usability issue sooner

[softprops]

Log the error message, probably via error! so that it appears in CloudWatch.

+1

[rimutaka]

I'll attempt a PR in a few days.

[rimutaka]

Actually, this is a breaking change. The existing code will compile, but may output nothing or some dummy text.

[softprops]

Actually, this is a breaking change.

You are fortunately afforded the luxury of timing here here. The current state of code has evolved much beyond what's been released in a breaking change sort of way. If there was a good time to make a change to improve usability but might be considered a breaking change, now is that time.

[rimutaka]

Logging errors from inside async fn run_inner requires these 2 dependencies:

simple_logger = "1.6.0"
log = "0.4.8"

and an init statement somewhere before error!() is called

simple_logger::init_with_level(log::Level::Info)?;

I'm inclined to make the loggers an optional feature, disabled by default.
The init will have to be done in the body of the lambda handler function to avoid conflicts and select the right logging level.

[davidbarsky]

Thanks for opening this issue! I'm personally inclined to use tracing over log(given that I'm one of the authors of tracing...), if only because it integrates with XRay already.

[softprops]

requires these 2 dependencies

One is an interface and the other should be a user choice. When you bind simple logger you remove a user choice. Please try to avoid removing user choice for logging!

An alternative is opting for your simple logger in the mains where you want the extra logging and set that to error or what have you.

I'm a fan of log if for no other reason is it's ubiquity. Trying to be unbiased here :)

tracing is nice but also feels like it should be a user choice

[davidbarsky]

Here are examples of what other runtimes are producing...

Thanks for the reference. I'm worried that we might limited in what information we can send to Lambda, but I'll need to dig into this: https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.html.

Log the error message, probably via error! so that it appears in CloudWatch.

+1. @nmoutschen and I are working on finishing up a tracing-xray integration that already works in this runtime. That might be another option here.

One is an interface and the other should be a user choice. When you bind simple logger you remove a user choice. Please try to avoid removing user choice for logging!

+1

I'm a fan of log if for no other reason is it's ubiquity. Trying to be unbiased here :)
tracing is nice but also feels like it should be a user choice

For sure! One of the things we've put a lot of effort into tracing is to enable existing log user to consume tracing-instrumented libraries (for instance, see the PRs I've opened on hyper and h2) with no performance or interop issues whatsoever. From the perspective of of something of like env_logger, tracing is log. tracing users, however, are able to get richer diagnostics and see higher performance when using a tracing Subscriber. We're not attempting to boil the ocean with tracing :)

[davidbarsky]

Sorry for accidentally closing this issue! Didn't mean to.

[rimutaka]

This snippet is from Cargo.toml (https://github.com/awslabs/aws-lambda-rust-runtime/blob/master/lambda/Cargo.toml#L9):

[features]
# no features by default
default = ["simulated", "derive"]
simulated = []

which doesn't make sense to me.

1. It says "# no features by default" while enabling derive and simulated.
2. I can't find any references to simulated in the code. Looks like mod simulated is used for testing only.

Shall we remove simulated from the list of features while I am at it?