I’m working with recursive loops right now and have some troubles with collecting the data at the recursive loop end.
The workflow shall run on a KNIME server. A certain analysis is run on all input rows with previously set user parameters. Afterwards, the user can select the rows to keep and which rows to run through the analysis again with new user parameters. I’m using a recursive loop, which includes setting the user parameters, running the analysis and selecting results to keep or to re-run.
Now my problem: The data passed to the first collection port is not collected. Selecting everything in any iteration is working fine. Selecting nothing is fine (recursive loop abortion caused by reaching the maximum number of iterations). But if I select a row in the first iteration and select all other rows in the second iteration, only the rows from the second iteration are collected. The row from the first iteration is vanished.
I built a minimal example to further test this and to play around with the recursion (attached). The “problem” is, that everything is working perfectly fine in the example. The workflow behaves as expected in the local AP and on the server.
Do you have any ideas, which could be implemented incorrectly? I double-checked every setting and compared them to my minimal example. I also re-implemented my actual workflow strictly following the set up of the minimal example. But I still get to the same issue. I have the impression, I’m just missing a small detail.
Thanks for your question, very interesting use of the recursive loop. I had never tried it before in such interactive scenario and didn’t know it was even possible.
Concerning you question, I copied your workflow to the KNIME community server webportal, tried it, and can confirm it works as described.
Therefore, it is going to be difficult to understand why it doesn’t work in your real case since the workflow you posted works fine. Are you sure the two workflow configurations are the same for the -Recursive Loop Start & End- nodes ?
Hope this helps at least for double checking that your minimal example behaviour is reproducible.
thanks for your answer and for checking my example workflow. I’m glad, I could show you something new!
I will double check the use case workflow again. It’s probably a faulty setting. I hoped for an answer here like “A common mistake using recursive loops is…” or “Have you checked setting …?”. But if the minimal example is working as expected, than the application to another use case should work as well.
I’m still not able to clearly identify the problem, but I was able to reproduce the issue with a minimal example. All I can say for now is: It has something to do with the Refresh Button Widget!
The minimal example is attached to this post. I you run through the workflow without using the refresh button, everything is running just perfectly. If you run through the workflow just using the refresh button in the first loop, everything is fine as well. But things seem to go down in the case of using the refresh button in recursive loop executions > 1.
Is this a bug or a just a “feature”?
Maybe someone can explain this behavior and may also recommend a solution.
I tested a few things to make sure, the issue really is about the refresh button. I would conclude, that it is about the refresh functionality and not the Refresh Button Widget only.
Alternative 1 is the same workflow as above without the refresh button but with the re-execution option of the single selection node enabled.
Alternative 2 is the same workflow as above without the single selection node but with the refresh button in combination with a table view node (to select an entry).
Let me see if I can find someone internally to help troubleshoot the problem, and if necessary, create a ticket. Thanks for your patience (and detailed description of the issue)!
Good catch @wurz.
Indeed, the re-execution messes up with the values collected by the loop end. I run a few tests and this seems to affect all the loop types and not only the more complex recursive loop you used in your example. I have created a ticket for our developers (internal reference AP-20463).
In the meantime, a possible workaround that I found for simple cases is to write the data in a temporary file at every iteration and read it after the loop end. The solution might be more complex for recursive loops, but it’s worth giving it a try.
Thank you very much for the big effort you put into bringing this up! I will keep you posted if there are any updates.
