Feature request: idempotency Middy middleware

[saragerion]

Use Case

Users who already use Middy middleware in their functions should be able to make their function handler idempotent via a makeHandlerIdempotent Middy-compatible middleware.

Solution/User Experience

import { 
  makeHandlerIdempotent,
  DynamoDBPersistenceLayer,
  IdempotencyConfig
} from '@aws-lambda-powertools/idempotency';
import middy from '@middy/core';

const config = new IdempotencyConfig({...});
const persistenceLayer = new DynamoDBPersistenceLayer({...});

const lambdaHandler = async (_event: any, _context: any): Promise<void> => {
  /* ...Function logic here... */
}

export const handler = middy(lambdaHandler)
  .use(makeHandlerIdempotent({ config, persistenceLayer });

The makeHandlerIdempotent middleware should work with both sync and async function handlers. The middleware should accept an object with mandatory persistenceStore and an optional config one. The former should be an instance of any class that extends BasePersistenceLayer, while the latter should be an instance of the class IdempotencyConfig.

Following the Powertools for Python decorator implementation, the middleware should:

• return early if the POWERTOOLS_IDEMPOTENCY_DISABLED env variable has a truthy value (using EnvironmentVariableService) - onBefore
• use the provided config object or instantiate a new one if none is passed - onBefore
• register the Lambda context into the config object (used to manage timeouts) - onBefore
• instantiate an IdempotencyHandler - onBefore
• call & return the IdempotencyHandler.handle() method - onBefore

This last step will ensure that the IdempotencyHandler will perform all the actions needed to make the function idempotent.

Given how Middy handles requests and errors, there's a chance that the current public methods of IdempotencyHandler might not be enough and we'd need to add additional public methods to call in the onAfter or onError phase.

Alternative solutions

No response

Acknowledgment

• This feature request meets Lambda Powertools Tenets
• Should this be considered in other Lambda Powertools languages? i.e. Python, Java

[dreamorosi]

As a result of the discussion in #1410 I have been thinking about how to implement this and realized that there's an added challenge related to how Middy works.

Middy allows middleware authors to return early in the before phase of a middleware. When this happens, the after and onError phases of the middleware that returns as well as all the other middleware in stack also skip these phases.

This mean that if the idempotency middleware is preceded or followed by other Powertools middleware they won't be able to perform any post-request action. This is problematic especially for the captureLambdaHandler middleware (as described in detail here) as skipping the after/onError phases means leaving the request segment dangling which can cause tracing data loss and in rare cases also stack overflow due to new segments being opened at every request and never closed.

This is not a case that is limited to the middleware being discussed in this issue and it also affects any custom middleware implemented by Powertools users so we will need to document and/or expose a way for middleware that do an early return to cleanup after themselves before returning.

I'm still unsure on the best way to handle this, but whatever solution we settle on will have to be adopted by this middleware, hence this note. I'll link back to this issue once we have more info.

[github-actions]

⚠️ COMMENT VISIBILITY WARNING ⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[github-actions]

This is now released under v1.9.0 version!