Forcing Sequential Processing after Split Out Node

Describe the problem/error/question

I am processing alerts (creating tickets) and want to merge some alerts into the same ticket. The “check for existing ticket” logic seems to work if my related alerts come in separate n8n executions, but related alerts during the same execution don’t get matched/merged.

I’m wondering if this is because my Split Out node is resulting in parallel execution of items.

  1. Could that be the case, or are there other possible causes?
  2. Would a Loop node after the split be the best way to prevent parallel execution? I was hoping to avoid the loop node because it seems to require separate loop and done forks.

Please share your workflow

Information on your n8n setup

Debug info

core

  • n8nVersion: 1.108.1
  • platform: docker (self-hosted)
  • nodeJsVersion: 22.17.0
  • database: sqlite
  • executionMode: regular
  • concurrency: -1

Hey! You are on the right track. Your code node is set to Run once for each item. This means you create individual items with _key but duplicates don’t currently get consolidated and flow downstream as individual items still.

You can revamp the code node or aggregate them (check the Aggregate node) afterwards, there will be multiple approaches. Let me know if I can help further with any and feel free to mark this as Solution if it helped :slight_smile:

For clarity, I’m not trying to merge the items/objects in the workflow. I’m trying to check if one item matches the the _key of a previous item (that previous item might have been in this execution or on a prior day). The subworkflow has a simple lookup like:

If the _key for this item already has a JIRA ticket with the same _key, then add a comment to the existing, don’t create a new JIRA ticket.

What I suspect is happening is that the n8n items are either being processed in parallel or procesed so quickly in succession that JIRA’s REST API (query for _key) doesn’t yet indicate that _key is already set on a ticket/issue.

In short, I just want to slow down execution of the n8n items and make them go sequentially.

I see, then I would recommend something like this, to process then in batches of 1:

Sounds good?

Thank you. I’m not sure if this is a quirk of the editor or if I’ve wired this wrong. I’ve pinned data in Normalize, but this still doesn’t seem to execute when I press Execute.

  • I don’t need the “Done” branch to go anywhere. Can it “dangle” or must I connect it somewhere?
  • I added the 1s wait just to give the JIRA API a chance to breathe.

You need some kind of trigger to press Execute. The Done branch can dangle, yes. Here, I’ve wired it for you:

1 Like

Apologies, I was trying to keep it simple and only show the relevant nodes. I had left out my schedule trigger.

Here is the whole thing:

I’m still not clear why two objects go into the Loop node but only one seems to come out.

You need to connect one of the nodes (Redis?) back to the loop, so it continues (a.k.a. have a closed loop). Check my last flow

Many thanks. I had seen that connection in your post but I didn’t really understand what it did so I left it out initially. Little did I know…

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.