RFC: New lambda timeout logger utility

[benheymink]

Description of the feature request

Problem statement

A suggestion to implement the equivalent of the Log Timeout middleware from the DAZN power tools. For those unfamiliar, this utility ensures a helpful message is logged out just before (configurable) a lambda function actually times out.

Summary of the feature

Main features:

• records an error log message invocation timed out (with the invocation event as attribute) when an invocation times out

Code examples

Usage would be familiar to anyone who has used the dazn variant:

import { logTimeout } from '@aws-lambda-powertools/logTimeout';
import middy from '@middy/core';

const handler = async (event, context) => {
  return 42
}

module.exports = middy(handler)
  // or .use(logTimeout(50)) to log the timeout error message 50ms before invocation times out
  .use(logTimeout()) // defaults to 10ms
}

Benefits for you and the wider AWS community

For those new to lambda/serverless function timeout can be a source of headaches, this makes it a lot clearer to anyone looking at a log why something went wrong!

Describe alternatives you've considered

Additional context

Dead simple implementation, just a wrapper around a setTimeout tracking how many ms are left in a function invocation., so will not add much bloat at all to the overall library/package.

Related issues, RFCs

[willfarrell]

I've been wondering if the node lambda runtime itself should handle this using an AbortController with a timer and pass in { signal } into the handler allowing external requests opened during the request to close safely and clean up before running all of the after/onError middleware. The node lambda runtime isn't OSS, that I know of, so hard to reach out to that team to collaborate. For v3 of middy we've added this functionality into @middy/core, defaulting to throwing a timeout error 5ms before the end of the provisioned max duration.

Our implementation: https://github.com/middyjs/middy/blob/release/3.x/packages/core/index.js#L100

[heitorlessa]

It'd be great to hear customer's interest here. We could certainly use company names and their use cases to help prioritize a feature request to support Lambda Lifecycle Hooks -- that would solve across runtimes and a more reliable solution to handle errors & out-of-band tasks (e.g., think multiple handlers for a given function, or a SIGTERM hook).

These would be a lightweight alternative to a Lambda Extension. It's also easier to grasp from a developer mental model within their programming language of choice

[shooit]

@heitorlessa we would be interested in lifecycle hooks at Stedi. My team and I'm sure many more have written a bunch of code to handle lambda timeouts and errors that would become simpler if natively supported by Lambda.