Workflow not working when launched from app

[francsoit]

Hello,
I'm working on a workflow, everything works great when I run it from the workflow interface.
When I'm running it from the app, I have an error on a loop ("Loop input is not iterable. Please change the loop input and try again."). When I check the loop input, it's an iterable array (even in the run from the app)

=> I use strictly the same startTrigger data, using "Use as an example JSON"
=> The workflow is deployed "Latest version deployed"

It feels like a bug...

[pyrrho]

Hello @francsoit!

Would you be able to share a screenshot or two of your loop node (and input nodes including your startTrigger)?

The workflow input from the App would also be helpful as it sounds like the structure of the data being passed to the workflow may be slightly off.

[francsoit]

Here is the run from workflow interface:

(input for the loop)

(run of the loop)

Here is when it's launched from the app :

(input for the loop)

(run of the loop)

=> The workflow is deployed "Latest version deployed"

I strictly use the same input data, using the "Use as an example JSON". When i click on that and run the workflow from the "Run button", it works immediately

[pyrrho]

Can you also share the CreateComeptenceFamile loop node (not the results, the actual setup)? I am assuming FamilleToCreateUniq is the input for the loop, but I am not certain.

[francsoit]

Yes it is, here is the screenshot:

Thank you!

[francsoit]

And to complete, here is a screenshot of the startTrigger data of both run:

[francsoit]

I got it to work by rewriting it in JS without lodash, is it possible that it comes from that?

[pyrrho]

It is definitely a possibility -- I doubt it is from the lodash library itself but perhaps in the default functionality or some other way in which the JS node is using the library.

I notice that you've also done a few in-line operations that start with the _.chain() function and I wonder if there is an issue with the statement being made all-in-one this way.

Sometimes I've had to break up these chained steps discretely to have the node work. Chain them back together and then the node gives an error.

Since you re-wrote this without lodash and had success it may be that you've introduced these discrete steps as well and we both might be seeing some weird interaction at the node level with chained operations.

[francsoit]

Interesting!
What's weird is that the node is not in a failed state, I even tried to chain it with a filter node, and it works. It stops working at the loop node..

[pyrrho]

Hmm. Very strange. The error message is so clear that there isn't an iterable value but your log shows the iterable value.

Have you tried remaking the loop node (to rule out some sort of strange "this node is corrupted somehow" issue)?

[francsoit]

Yep I tried to create another loop node with just a script action that return the value, no luck I got the same error..
I will try to reproduce on a new workflow to isolate the error

[francsoit]

So here is a link to a simple workflow that reproduce the error:
https://www.dropbox.com/scl/fi/n7bskfobd579x0m0bd067/workflow.json?rlkey=2l7jvgzeg6mythcg0sgxenun1&dl=0

When you run it from the workflow interface, it works, when you run it from an app, you get the "loop is not iterable" error

[pyrrho]

Can confirm this behavior even in the test app. Works great in the workflow run, doesn't work at all in the app triggered run.

@Tess I don't even know what this could be.

[Shawn_Optipath]

Hi @francsoit,
I tried your sample workflow and got it to work after reproducing the error.

I changed code2 to:

return _.chain(code1.data)
  .filter(function(item) { return item.type === "a"; })
  .uniqBy("value")
  .map("value")
  .value();  // <-- Ensure only the array is returned

Issue: The loop (loop1) expected an array but was receiving an object from code2:

{
  "data": ["blabla1", "blabla3", "blabla4"],
  "metadata": null,
  "value": null
}

Fix: Updated code2 to return only the array, so the loop gets:

["blabla1", "blabla3", "blabla4"]

The loop now correctly receives an iterable array instead of an object.

[pyrrho]

Awesome catch on the object return. It does look like an array but we are seeing the whole object. I think also using the .data property in the loop like {{ value.data }} would also make the loop node happy.

ETA: Actually, you'd need to send the return the data property from the current code -- not different than just using the .value() function at the end of the chain.

[francsoit]

Oh great, thanks for your finding @Shawn_Optipath !
It would be perfect if the way the workflow is executed was exactly identical between the two way to call it

[francsoit]

And thanks a lot @pyrrho for your help!