You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
dreamorosi opened this issue
Jul 11, 2023
· 2 comments
· Fixed by #1616
Assignees
Labels
batchThis item relates to the Batch Processing UtilitycompletedThis item is complete and has been merged/shippedinternalPRs that introduce changes in governance, tech debt and chores (linting setup, baseline, etc.)
The current implementation of the Batch Processing utility allows you to register an handler function that is executed for each record in a batch. This function can be both synchronous and asynchronous. In order to allow for async functions the current process() method has been implemented as async and always returns a Promise.
This requires the caller to have to await the result and handle the promise. When the caller passes a synchronous handler this might result counterintuitive, even though the addition of a Promise technically is a no-op.
This discussion arose during the review of the first PR for the utility (here), however at that time it was too early to make a decision and so we have decided to postpone the topic until later in the implementation.
Why is this needed?
So that we can review whether the current implementation is appropriate and decide if we need to change the types, add a new methods to distinguish between sync/async processing, or split the classes entirely.
Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET
Future readers
Please react with 👍 and your use case to help us understand customer demand.
The text was updated successfully, but these errors were encountered:
dreamorosi
added
internal
PRs that introduce changes in governance, tech debt and chores (linting setup, baseline, etc.)
confirmed
The scope is clear, ready for implementation
batch
This item relates to the Batch Processing Utility
labels
Jul 11, 2023
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.
batchThis item relates to the Batch Processing UtilitycompletedThis item is complete and has been merged/shippedinternalPRs that introduce changes in governance, tech debt and chores (linting setup, baseline, etc.)
Summary
The current implementation of the Batch Processing utility allows you to register an handler function that is executed for each record in a batch. This function can be both synchronous and asynchronous. In order to allow for async functions the current
process()
method has been implemented asasync
and always returns aPromise
.This requires the caller to have to
await
the result and handle the promise. When the caller passes a synchronous handler this might result counterintuitive, even though the addition of aPromise
technically is a no-op.This discussion arose during the review of the first PR for the utility (here), however at that time it was too early to make a decision and so we have decided to postpone the topic until later in the implementation.
Why is this needed?
So that we can review whether the current implementation is appropriate and decide if we need to change the types, add a new methods to distinguish between sync/async processing, or split the classes entirely.
Which area does this relate to?
Other
Solution
No response
Acknowledgment
Future readers
Please react with 👍 and your use case to help us understand customer demand.
The text was updated successfully, but these errors were encountered: