As described in the title, my merge node function most of the time. But it fails occasionally. I have tried comparing input1 and input2 from both successful and failed merge. They look exactly the same in terms of the JSON data structure.
I’m wondering if there is any other thing that I would need to pay attention to when merging data.
Hi @BeStill 
Sorry to hear you’re running into this!
Could you provide us with a workflow where you’re seeing this behaviour that we can reproduce this with?
If you could also let us know the following, that would help:
Hi @EmeraldHerald ,
Input 1 and Input 2 for the merge node are just JSON out from the previous node. Both failed and success one look identical structural-wise. But those failed one will just fall into second group of output (from the output drop down list), and didn’t get merged as it supposed to be.
Below are some version n8n setup information:
By the way, what are the differences between those two EXECUTIONS_PROCESS settings? Because I have ran into problem where the interval between each run is too closed, which even looks like multiple runs are completed in parallel, and causing logical issue. Just wondering if the workflow could finish each run completely then start the next one. More like a depth first run instead of a breadth first run? But how would n8n take care of the ordering if there are branches in each run.
Hi @BeStill - thanks for that information! Could you share some example data I could use to try to merge, as well as your Merge node settings?
main means all executions will run in the main n8n process, whereas in queue mode you run multiple instances of n8n: one main instance is required for triggering some workflows and allowing user access through the UI, while the other worker instances process the executions. This requires more setup, but is great for scale. You can find more information about this here.
Hi @EmeraldHerald - Thanks for your help. Please see the below inputs for a failed merge. For the merge node settings, I have included the workflow as well. I’m basically doing a left join here. However, n8n would just output what I have for input 1 as a result but in a separate output tab for some reason.
Input 1
[
{
"_index": "index-2023.08.01-000000",
"_type": "_doc",
"_id": "a_sYcbTySeiLQ3JZQ0iEEQ",
"_score": 3,
"_source": {
"@timestamp": "2023-08-01T00:20:42.422136+00:00",
"alert_id": "a_sYcbTySeiLQ3JZQ0iEEQ",
"rule_name": "Just a title",
"rule_severity": 2,
"alert_key": "1.1.1.1",
"lookup_matches": null,
"user_name": [],
"src_ip": [
"8.8.8.8",
"1.1.1.1"
],
"dv_dst_ip": [
"20.20.20.20"
],
"hostname": []
}
}
]
Input 2
[
{
"_id": "~21700856",
"_type": "Alert",
"_createdBy": "[email protected]",
"_updatedBy": "[email protected]",
"_createdAt": 1691108609952,
"_updatedAt": 1691108610140,
"type": "Alert",
"source": "XXX-8.8.8.8-1.1.1.1",
"sourceRef": "a_sYcbTySeiLQ3JZQ0iEEQ",
"title": "Just a title",
"description": "Alert from Rules",
"severity": 2,
"date": 1691108442422,
"tags": [],
"tlp": 2,
"pap": 2,
"read": true,
"follow": true,
"customFields": [
{
"_id": "~rmx3z-cx4hk-19ud-3a8",
"name": "alert_id",
"description": "Unique Alert ID",
"type": "string",
"value": "a_sYcbTySeiLQ3JZQ0iEEQ",
"order": 0
}
{
"_id": "~rmyov-cx4hk-19ud-9hc",
"name": "abuseipdb_score",
"description": "AbuseIPDB Score",
"type": "string",
"value": null,
"order": 0
}
],
"observableCount": 3,
"caseId": "~2490424",
"extraData": {}
}
]
Hi @BeStill - So when following this example, I’m getting this merge of input 1 and 2:
[
{
"_index": "index-2023.08.01-000000",
"_type": "Alert",
"_id": "~21700856",
"_score": 3,
"_source": {
"@timestamp": "2023-08-01T00:20:42.422136+00:00",
"alert_id": "a_sYcbTySeiLQ3JZQ0iEEQ",
"rule_name": "Just a title",
"rule_severity": 2,
"alert_key": "1.1.1.1",
"lookup_matches": null,
"user_name": [],
"src_ip": [
"8.8.8.8",
"1.1.1.1"
],
"dv_dst_ip": [
"20.20.20.20"
],
"hostname": []
},
"_createdBy": "[email protected]",
"_updatedBy": "[email protected]",
"_createdAt": 1691108609952,
"_updatedAt": 1691108610140,
"type": "Alert",
"source": "XXX-8.8.8.8-1.1.1.1",
"sourceRef": "a_sYcbTySeiLQ3JZQ0iEEQ",
"title": "Just a title",
"description": "Alert from Rules",
"severity": 2,
"date": 1691108442422,
"tags": [],
"tlp": 2,
"pap": 2,
"read": true,
"follow": true,
"customFields": [
{
"_id": "~rmx3z-cx4hk-19ud-3a8",
"name": "alert_id",
"description": "Unique Alert ID",
"type": "string",
"value": "a_sYcbTySeiLQ3JZQ0iEEQ",
"order": 0
},
{
"_id": "~rmyov-cx4hk-19ud-9hc",
"name": "abuseipdb_score",
"description": "AbuseIPDB Score",
"type": "string",
"value": null,
"order": 0
}
],
"observableCount": 3,
"caseId": "~2490424",
"extraData": {}
}
]
If that’s not what you expect, can you let me know in JSON format what you’re looking to achieve and how you expect the merge to look?
Hi @EmeraldHerald - This looks good to me.
But mine just did get merge at all in the flow. The output of this merge node was just input 1. But this is happening occasionally. Some of them get merged just fine and got output as you do.
Hmm, is it possible that perhaps in your workflow, a previous node isn’t receiving all the data that you might need to merge? If you could give a JSON example of when this doesn’t work, I can dig a little deeper into this with you 
Hmmmm… the input 1 and input 2 I sent you are the exact inputs that doesn’t work.
What about the arrival time of input 1 and input 2? Would that affect the output as well?
It very well might - I’m not sure of your full workflow, but that merging was through setting those values through the code node and having them be available for the merge node at the same time.
I see. Because input 1 is from the main workflow, input 2 would need a query from an external resource. Do you think there is an option to let the merge node wait for both input to arrive?
Can you provide a screenshot of an execution log where the merge hasn’t worked as you thought it would? That might help 
A node that comes before the merge might not be outputting data as you’d expect.
Hmmmm what do you mean by execution log?
Both input 1 and input 2 are outputing the Json I posted. There is no other nodes in between.
And the out of that merge is just identical to input 1.
@BeStill I was mainly just curious if your assumption was correct, in that one of your sources was not providing data to the merge node 
Do your executions history in the n8n UI, or even n8n logs show this?
I believe the merge node should wait for both inputs, but you could try a wait node after where you’re pulling in the data to see if that makes a difference.
@EmeraldHerald Hmmmmm I have checked the executions history. I’m pretty sure both inputs have provided necessary data for the merge node. Although I’m not sure why the single execution was split into two runs for input 1, but I believe both input 1 and 2 has provided enough information for a merge.