Result Error logging at the end of execution

[lxwbr]

I am using the latest master (ebc5474) and structure my project according to this example: https://github.com/awslabs/aws-lambda-rust-runtime/blob/master/lambda/examples/hello-without-macro.rs

What I ran into is that if having e.g. a DynamoDB call like this:

let result = dynamodb_client.update_item(update_item_input).await?;

which is returning a Result<UpdateItemOutput, RusotoError<UpdateItemError>> and RusotoError implementing the std::error::Error, I wouldn't see the error in CloudWatch logs. The lambda would still fail, but I wouldn't be able to have a look at what exactly failed.

Is there a way that I could have a general match on the async fn func(event: Value) -> Result<Value, Error> at the end of the execution of the lambda and be able to log the error via println?

Coming from Typescript, I would put a try catch around my whole function and log the error. Basically I am looking for something similar here.

[davidbarsky]

Is there a way that I could have a general match on the async fn func(event: Value) -> Result<Value, Error> at the end of the execution of the lambda and be able to log the error via println?

Few thoughts:

• That's what the previous error handling strategy attempted to do, but I was (personally) unsatisfied with the costs of use.
• I've previously considered something like std's panic_hook for this library. Would that something that would be useful in this Lambda runtime as a general error-reporting mechanism?
• We can and should log errors in the runtime—that's some really low-hanging fruit that I'll address in internal: internal cleanup; correctness #214.

Additionally, if you're logging, might I suggest checking out tracing? It's the open source project that I spent most of my time in recent months on. It has:

• Structured key/value pairs.
• Drop-in replacement for log.
• Units of work called "spans"
• Neat error reporting via tracing-error.

It doesn't yet have integration with CloudWatch's embedded metrics format or XRay, but I know of an Amazon-internal library that does integrate with CloudWatch's embedded metrics format—I think that team said they'd be happy to open-source it.

[softprops]

Coming from Typescript, I would put a try catch around my whole function and log the error. Basically I am looking for something similar here

Same rules apply in rust. You can just take of the ? on await? That just propagates the error up. Instead, inspect the error and do something with it. A simple case of prefixing with a pattern to filter on in cloudwatch insights or a log metric filter can get you pretty far with low effort.

use lambda::handler_fn;
use serde_json::Value;

type Error = Box<dyn std::error::Error + Send + Sync + 'static>;

#[tokio::main]
async fn main() -> Result<(), Error> {
    let func = handler_fn(func);
    if let Err(e) = lambda::run(func).await {
       println!("error: {}", e);
       return Err(e);
    }
    Ok(())
}

async fn func(event: Value) -> Result<Value, Error> {
    Ok(event)
}

[mickdekkers]

@softprops it seems that doesn't quite work. Nothing is printed when func returns an error. I think this might be because lambda::run doesn't propagate the error from the func call.

A workaround is to use an inner function and print the error from that:

use lambda::handler_fn;
use serde_json::Value;

type Error = Box<dyn std::error::Error + Send + Sync + 'static>;

#[tokio::main]
async fn main() -> Result<(), Error> {
    let func = handler_fn(func);
    lambda::run(func).await?;
    Ok(())
}

async fn func(event: Value) -> Result<Value, Error> {
    if let Err(e) = func_inner(event).await {
        println!("error: {}", e);
        return Err(e);
    }
    Ok(())
}

async fn func_inner(event: Value) -> Result<Value, Error> {
    Ok(event)
}

This does work for me.

Note: tested with revision ebc5474.

[coltonweaver]

With the contribution from @rimutaka I believe the content of this question is addressed. I'm going to close this issue, feel free to reopen if you still have questions.