improv(idempotency): handle functions with no return value

[dreamorosi]

Summary

Changes

Please provide a summary of what's being changed

This PR improves the Idempotency utility by allowing it to be used on functions that have no return value (i.e. void/undefined). This is useful when you want to make idempotent a function that causes side effects only, but has no return value.

Before this PR the utility would not work on these functions because it would expect the function being made idempotent to return a value that would then be stored in the persistence layer.

As described in the linked issue, the initial plan was to align with how Powertools for AWS Lambda (Python) handle this edge case and store the value as 'null' into DynamoDB, however after some initial tests it became clear that this was not a viable option due to the fact that it would have become impossible to covert the value back to the original undefined when retrieving the idempotency record.

Likewise, storing the item with the attribute set to Null (DynamoDB attribute type) was not an option due to it being converted to JavaScript null.

To preserve the ability for customers to return null or 'null' (string), I decided instead to avoid storing the attribute altogether when the function returns undefined, since this is the closest value (or rather lack thereof) to the one being returned.

In order to implement this logic I had to do some light refactoring in the IdempotencyHandler class and introduce an intermediary data structure that makes it explicit when the return value is undefined vs when undefined is used as a mean of control-flow (it'll be clearer when you see the code in the diff I hope - if it's not, please ask).

Please add the issue number below, if no issue is present the PR might get blocked and not be reviewed

Issue number: #2505

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[am29d]

Thanks for PR, I see the reasoning behind the change. I was on the fence first, but it's much cleaner for the user to not think about return value, otherwise we'd need to enforce to return something.

One change request: could we add e2e test to cover this one case?

[dreamorosi]

@am29d - I have modified one of the e2e test cases to return undefined and adjusted the assertions to test that the case is handled correctly.

[dreamorosi]

Updated integration tests are passing: https://github.com/aws-powertools/powertools-lambda-typescript/actions/runs/9218785428

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud