Currently I have problems with SplitInBatches.
1+2 = 3 rows but somehow i get only one row
I’m just confused now.
Am I perhaps making a simple usage error?
The merge only pulls that function node once. To force it to run every time you need an input into that function node to have it run every time.
So the 3rd run you are not getting data in that merge from that function node so it cannot continue.
you can fix it for example with:
1 Like
@BramKn the issue is than that the first data gets dublicated and the last gets ignored:
Input:
The first item creates the file. The last 3 appends to the file.
Currently:
The first item creates the file. The first item and 2 items gets append.
yeah my new line was just an example. I have no idea what you are doing.
Glad it is fixed!
@BramKn I also do not know what I’m doing xD
Thanks for your help. This merge node and SplitInBatches is often a problem for me. My brain spins around there very often.
yeah its quite annoying sometimes. I tent to use sub workflows, which relieves some of the headaches as well. 
2 Likes
That would actually be a good idea as a new feature. A possibility to start nodes as subworklofw. So a nested graph.
uhhhhh, not sure how you see this.
We already have an option for sub workflows by triggering other workflows with the execute workflow node. 
might be missing the point.
@BramKn It’s just when my builds a cohesive routine that’s not exactly practical either.
You go in the first flow and then you see: Oh it calls another flow and you have to navigate in this one again. And you see there: Oh the data comes back wrong. Okay you can only fix it a little bit so I have to switch back to the other flow.
yeah debugging can be annoying indeed.
I think I understand what you want to do. you simply want it to act as a sub workflow inside another workflow not have it seperate?
what about making the debugging easier? would probably be easier to accomplish.
no idea how exactly though 
Oh that would be too easy xD
1 Like