We’ve just found that the recursive loop end doesn’t work in the way we’d expect.
Expectation: the columns can be provided in any order and the rows will be combined in the same way the concatenate node does.
Reality: the recursive loop end does no validation on column order and concatenates data by index, outcome of this is the data is in the wrong columns in different rows.
Example workflow that shows the problem:
In the example workflow we see the red x giving this message:
ERROR Recursive Loop End 2:7 DataSpec generated by configure does not match spec after execution.
Though this didn’t happen our actual workflow, we get no warning on that.
A work around is to add a Column Resorter node before the recursive loop end:
I guess our preferred behaviour would be to have it work like the concatenate and handle different column orders. If this is computationally more expensive (which presumably it is) maybe it could be optional like other loop ends can have a changing table spec?
Alternatively could the node fail for changing column order instead of proceeding? I checked the node description and it doesn’t mention that column order must remain the same between iterations.
This behaviour is seen in at least 4.1 and 4.2