SplitInBatches Loop/Done after update 0.220.0

Hi.

I noticed that with the new update, the old SplitInBatches node I used in my workflows was overwritten with the updated version of the node ending the loop with the summary of the items in the loop.

It’s great there is this additional Done Branch, but it messed up my workflows.
Before the update, it ended with the last result and moved on with the next batch, which I found useful, especially when it was part of a separate subworkflow. Now, instead of the last item, it outputs the “Done” summary and does it in the 2 Branch, which stops the workflow.
Is there a way of turning this summary/branch off?

BTW, I had always thought, that the nodes I used before the update don’t change after the update, so that I can rely on the solutions I have implemented in the workflow to work the way they are, but it seems to be different here.

Or am I doing something wrong again?:wink:

2 Likes

Thanks a lot for making us aware of this problem. In this case, should the behavior not have changed, only an additional output got added. We will investigate what is going on.

Very sorry, I am sadly not able to figure what exactly breaks your workflow. Can you please share a simple example workflow that shows the problem. We can then debug with the help of it and fix the problem asap. Thanks a lot for your help!

The issue only appears where the subworkflow (created with execute Workflow node) ends the loop with the SplitInBatches node.
Before the update 0.220.0, such a subworkflow outputted the last item into the primary workflow, and now it outputs two Branches. The first one outputted by the Execute workflow node in the primary workflow is empty (as it involved the split items one by one in the subworkflow) and the second Branch outputs the summary (“Done”).

I have workflows that make use of the info of the last item the subworkflow finished on, but I managed to find a workaround by adding Set nodes to the subworkflows that ended up with SplitInBatches nodes that calculate the info of the last item (as the number of items varies).

I am sure there is value to the updated SpitInBatches node, but I got surprised that the nodes got updated across all workflows.

I was under the impression, that in order for me to use the updated node, I would have to use a fresh node and the code of those already used in the workflows remains the same.

Hey @Rafix,

Thanks for that, We have been able to reproduce the issue and have created NODE-414 as the internal dev ticket for it.

Most of the time you are correct we will version a node if there is a good chance that the change will potentially break anything. In this case we didn’t version the node as our tests were showing everything was ok and working as expected. What we have found though which you might find interesting is the issue is not with the Split in Batches node but actually with the Execute Workflow node, If your workflow ends with a multi output node it causes the Execute Workflow node to also output multiple branches.

We are currently thinking about the best way to handle this.

2 Likes

How can I use more than one split batch?

So if the workflow ends with a SplitInBatches node or an IF node with both True and False results, is there a way to set the data of which Branch will be moving the parent workflow forward?

For the time being, I have been making workarounds in order for the proper data to be forwarded the way it was before the update and setting Execute Workflow nodes to “Always Output Data” in order for the parent workflows to work properly.

@Ruan17 Welcome to the community but please open a new thread for that question as it has nothing to do with the current discussion and else stuff gets very messy. Thanks!

@Rafix You can do that by making sure that the last node that gets executed returns the data on the first output. But if I would be you I would simply downgrade to a previous version. You should be able to upgrade again in a few hours once we released a bug-fix version. The PR for the rollback is ready and will be merged soon.

@jan Thank you very much for the support and your suggestion.
I managed to fix my workflows, but I will revert if necessary.

Best regards

Thanks a lot for your patience! We just released [email protected] which reverted the change.

Really sorry about that issue!

Here also a post about it here, to make sure that all people that already started to use that new output know what to do:

1 Like

Thank you for addressing and fixing the issue.

The idea behind the improvement will definitely prove useful, but I must say that I really appreciate the nodes not having forced updates and leaving it to the user to decide whether they’d like to go with the “new and improved” version of the node or copying the already familiar solution with the old code they have implemented in their workflows already.

Although, that most likely results in community suggestion posts inquiring about what has already been implemented with the updated version, it could bring in some unique feedback from completely different perspectives.

Nevertheless, can’t wait to update to the new release.

Sorry, there is maybe a misunderstanding. We never force-upgrade the version of nodes in people’s workflows, but what we always did, is improve the existing versions of nodes. That could be fixing bugs, adding new resources, operations, options, and so on. If we had created a totally new version of the nodes every time, things would have become unmaintainable (but we are thinking about ways how to improve that in the future)

You and everybody else did not realize that because we always ensure they are not breaking existing behavior as that is for sure our top priority.

It was also not different in that case. There was however one difference, for the first time ever, did we add an additional output. I thought about it a lot and tested everything and tried to think about possible issues but could not think of any. But as it turns out, there is this one edge case (having the node in a sub-workflow and returning the data in the loop) where it actually causes problems and which I did overlook. So we will for sure never do that (adding additional outputs to an existing node version) ever again!

That this did happen is bad but sadly never 100% avoidable. Even though we try to get as close as possible by adding tests, improving processes, and so on. But no matter if it is the code in a node (like in this case) or any of the underlying code we constantly change everything. Also there we try very hard to make sure that nothing breaks, but no matter how hard we try, there will always be instances where we fail as n8n is a very complex application, and nobody is perfect.

So can sadly not promise there will not be issues again in the future. That said, we are obviously working hard on making sure that happens as little as possible and so constantly improve. Right now we are for example in the middle of changing our release processes. That involves many things, but one of the most important changes is how we label versions and how we back-port fixes. So very high level will we, in the future, have a clear stable version (lagging slightly behind + includes all bug fixes) and a more experimental one which includes all the new features and changes.

We, for sure, should have done that already a long time ago. But better late than never. And from that point, people can then finally decide themselves what they care about most. Having the latest features available or having the most stable version.
Until we finally have that officially in place, I would already suggest staying 1 or 2 minor versions behind to reduce the chance of hitting newly introduced bugs.

So really, thanks a lot for your feedback and for taking the time to share it with us!

4 Likes

Thank you for taking the time replying to my question.

I think you are doing a marvellous job, and both n8n and this community are seriously among the most impressive things one can come across online, IMHO.

I think I understand what you mean now, when you talk about updating the nodes.

I was under the impression, that nodes in the workflows I had created before are not updated as their interface didn’t change, and I could always copy old version of nodes from the older workflows, whenever I needed to.

Now, I understand that they are being updated, but their functionality is restricted to and dictated by their “out-of-date” UI.

(I hope I am clear. I am not a programmer. I learn as I go;)

I also realise, that with my self-hosted instance, I am taking a tremendous advantage of what you are working so hard on, and always try to do my best to either figure out the solution on my own or wait patiently for an update and most of the time not before I had spent hours if not days on trying to make things work.

I usually assume, that if something is not working, I haven’t learnt how to you use properly yet.

The fact that it is unavoidable is 100% understandable. Nothing is perfect, nor should it be.

That being said, I like to believe that my feedback is at least somewhat valuable and will help improve an already impressive solution that is n8n.

Best regards!

1 Like

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