Typebot flow is triggered multiple times during conversation

[dohkotechnology]

When a user sends multiple messages in quick succession (e.g., "Hi", "How are you?", "What's up?"), the Typebot flow is triggered multiple times—once for each message. This results in the Typebot responding multiple times. This issue is not limited to the initial step; it can occur at any point in the Typebot flow if the user sends multiple messages in a short timeframe.

Expected Behavior:
The integration should handle multiple incoming messages in a way that prevents the Typebot from being triggered multiple times unnecessarily. For example, it could ignore subsequent messages until the current flow step is completed. I'm trying to create a bot to get some info from the clients before transferring them to an agent. I also can't get the bot to "sleep" because it triggers with every message.

Steps to Reproduce:

• Set up a Typebot flow in N8n.
• Send multiple messages in quick succession (e.g., "Hi", "How are you?", "What's up?") to the integrated channel.
• Observe that the Typebot flow is triggered multiple times, leading to duplicate or overlapping responses.

Anything I could try?

[devlikepro]

Hi! Yeah, looks like you need to add some sort of "mutex/lock" on n8n side, so it does not execute the same workflow per chat id (phone number) at the same time.

You can try adding redis node and add lock there with some TTL and during the period of lock ignore other messages (or send it later, depends on your usecase)
https://docs.n8n.io/integrations/builtin/app-nodes/n8n-nodes-base.redis/

[dohkotechnology]

Thanks for the quick response! However, wouldn't this approach prevent messages from being sent within the same workflow? The solutions I came up with would lock the entire n8n flow, meaning even messages from the chatbot itself wouldn't be sent.

I can't imagine how I would prevent triggering a new IVR within a client that already has an IVR in progress.

[devlikepro]

You don't need to have only one lock, but more like "per chat id" lock, like

lock:typebot:chat:{chatId}

You lock it before starting processing the message (with some timeout/ttl) then you release it at the end
If lock exists - drop that message, it means the typebot is processing it already.
Alternative would be no to drop, but delay it - it depends on your usecase, actually.

[devlikepro]

(c) ChatGPT

====

To ensure that only one n8n flow executes per chat ID at a time, you can use Redis as a distributed lock. Here's how you can implement it using the Redis node in n8n:

---

Solution: Using Redis Lock Mechanism

You can use SET with NX (Not Exists) and an Expiry (EX) to acquire a lock before executing your flow.

Steps to Lock Execution Per Chat ID

1. Use a Redis node (SET) at the start of the workflow:

   • Key: lock:chat:{chat_id}
   • Value: 1 (or a timestamp)
   • Expiry: Set a reasonable time (e.g., 60 seconds)
   • Options: NX (Only set if the key doesn’t exist)

2. Check if Lock Exists:

   • If the SET command succeeds (returns OK), proceed with the workflow.
   • If it fails (returns null), it means another instance is running, so exit the flow early.

3. Execute your logic (process the chat message).

4. Use another Redis node (DEL) at the end of the workflow:

   • Delete the key lock:chat:{chat_id} to release the lock when done.

---

Implementation in n8n

1. Add Set node to get the chat_id

• Extract the chat_id from the message or input.

2. Add a Redis node (SET) for Locking

• Mode: Set
• Key: lock:chat:{{$json["chat_id"]}}
• Value: 1
• Expiry Mode: Set Expiry
• Expiry (seconds): 60 (adjust based on your process duration)
• Set mode: NX (Only if key does not exist)

➡ If this succeeds (returns OK), proceed. Otherwise, terminate.

3. Add a IF node to check Redis response

• If Redis response is null, exit (another flow is running).
• If Redis response is OK, continue.

4. Add your logic (processing messages, etc.)

5. Add a Redis node (DEL) to release the lock

• Mode: Delete
• Key: lock:chat:{{$json["chat_id"]}}

---

Handling Failures

• If the workflow crashes, the lock will be automatically removed after the expiry time.
• If needed, you can add error handling to ensure the lock is always released.

---

Example Workflow Logic

[Webhook] -> [Extract chat_id] -> [Redis (SET Lock)] -> [IF Redis OK?] -> [Process] -> [Redis (DEL Lock)]
                             |                    |
                             |                    └── (Lock exists) → [Exit Workflow]
                             └── (Lock acquired) → Proceed

---

Would you like an n8n JSON workflow export for this setup? 🚀

[dohkotechnology]

I think I get the mechanism itself, but I’m having trouble seeing where it would fit into the current N8N flow to work as expected.

Could you point me to where exactly I should add this in the flow?

[devlikepro]

before Check TypeBot Session Exists