Describe the problem/error/question
In our workflow, we are encountering a blocking issue when multiple messages from different users are processed in parallel. Specifically, when messages follow different branches—one for users already registered and another for those who are not—the process in the false branch (the registration branch) tends to get stuck. This happens when the workflow attempts to send a registration prompt and wait for a response, which can lead to conflicts and blocking if executed concurrently.
What is the error message (if any)?
The error message that we observed in some instances is related to a type conversion issue. For example, an error like:
“Conversion error: ‘xxxxx’ can’t be converted to an array”
This occurs when the workflow tries to evaluate a property (such as the length of an array) on data that is actually returned as a single object rather than an array. This mismatch can cause the workflow to block or fail, especially when handling parallel executions.
Please share your workflow
Our workflow consists of several key components:
- A Telegram Trigger node that initiates the process when a message is received.
- A Supabase query node that checks if the user is already registered by fetching user data.
- A Conditional (If) node that determines which branch to follow based on the existence of a user record.
- One branch is taken if the user is found (registered), and the other branch is for initiating the registration process.
- A sendAndWait node in the registration branch that sends a prompt to the user and waits for a response.
The blocking issue appears when two messages from different user IDs are processed at the same time. Each execution is independent, but if the condition checking is not robust—such as using a method that expects an array when the data is a single object—it can lead to conflicts. Using a condition like “exists” on a property (e.g., checking if data.id exists) instead of trying to measure an array’s length can isolate each workflow execution and help avoid these conflicts.
This design ensures that each user’s workflow context remains isolated, reducing the risk of one execution blocking another.
## Information on your n8n setup
- **n8n version: 1.81.4
- **Database (default: SQLite):**Supabase
- **n8n EXECUTIONS_PROCESS setting (default: own, main):** main
- **Running n8n via (Docker, npm, n8n cloud, desktop app):**n8n cloud
- **Operating system:**windows