Current workflow of the solution is implemented with:
- Lambda --> DynamoDB --> DynamoDB Streams --> Lambda --> State Machine (Lambas)
In a near future, the workflow will also save the "response" messages by the chatbot in the same DynamoDB Table, making the workflow to look something like this:
- Lambda --> DynamoDB --> DynamoDB Streams --> Lambda --> State Machine (Lambas) --> DynamoDB --> DynamoDB Streams (NOT INTENDED)!!!!
So when the "answered messages" are added to the DynamoDB Table (kept with Single Table Design), it's important to avoid enabling the streams to be sent to the State Machine (as these are not user's messages, only the chat history...).
The proposed solution is to update the workflow to be:
- Lambda --> DynamoDB --> DynamoDB Streams --> EventBridge Pipe --> Lambda --> State Machine (Lambas)
With the correct EventBridge Pipe filter, the infinite loop can be avoided for the "answered responses" because of filtering the PK/SK.
Current workflow of the solution is implemented with:
In a near future, the workflow will also save the "response" messages by the chatbot in the same DynamoDB Table, making the workflow to look something like this:
So when the "answered messages" are added to the DynamoDB Table (kept with Single Table Design), it's important to avoid enabling the streams to be sent to the State Machine (as these are not user's messages, only the chat history...).
The proposed solution is to update the workflow to be:
With the correct
EventBridge Pipefilter, the infinite loop can be avoided for the "answered responses" because of filtering the PK/SK.