Strange behaviour with if nodes - have to manually click both branches

[mrchrisadams]

HI there,

I’m trying to debug a workflow, with an if node, and for reasons I don’t fully understand.

When I this workflow triggers on an weekly job, even though I know there is data flowing through ought to flow end flowing down to branching structures, it only ever seems to flow done the ‘false’ branch when run unattended.

If I open this workflow, then manually click each node, I’m able to see the data that passes a ‘true’ test, and by manually clicking each node I would expect data to be passed along, I can end up with the result I want of X new sign ups for a form being added to a mailing list, or slack workspace.

But for the life of my I can not understand what this is happening. I’ve been coding for at least ten years, and I’m trying to build these workflows to make them more maintainable than pure code for non developers, but this weird ‘only following a true branch when you watch a workflow and manually click the nodes that data ought to pass through’ behaviour has me fully stumped.

Here’s what my workflow looks like

I’ve attached the code below.

The workflow is designed to be run every week, and it should:

• fetch the latest joiners who have entered info via a google form
• filter out all the people names older than a week
• add the new email addresses to mailchimp (addresses already in the system should be ignored, or ideally, we should have a graceful error recovery, and PUT them instead)
• pull out all the email addresses and send a single message into a slack channel, so one of our staff can manually add the new members, before deleting the message.

This fires every Monday, but as mentioned before only the ‘false’ branch is evaluated. What am I doing wrong here?

As mentioned - the code.

[MutedJam]

Hi @mrchrisadams, do you store your workflow executions (this can be configured via the Workflow Settings)?

If so, my first step would be to check if there is any unexpected in the behaviour around the date/time calculations/comparisons you are performing. The recent version 0.146.0 also had changes to the Date & Time node, so updating beforehand might be a good idea. In particular, I’d verify the the values you see in your unattended execution match the ones you get when manually executing.

From taking a quick look, there’s also one somewhat unexpected expression in the CAT joined in last week? node:

So this looks like a 0 is always appended to the parsed_timestamp value of the input item, which would be worth looking at.

In order for us to reproduce this, could you share some example data you are reading from your Google Sheet?

[mrchrisadams]

Thanks for response @MutedJam , and sorry it took a while.

Below is a sample of the data doing into the CAT joined in the last week? node

[
  // these are two which should be filtered out, and are successfully being filtered out
  {
    "Timestamp": "7/15/2019 18:20:21",
    "Email Address": "[email protected]",
    ,
    "Our weekly CAT newsletter": "Sure, sign me up",
    "City and Country": "",
    "Why are you interested in joining? ": "Shutdownforfuture",
    "What's the main thing you'd like to offer as a part of the community?": "Networking and it knowledge",
    "Code of Conduct": "Yes I have read the code of conduct, and agree to follow it.",
    "parsed_timestamp": "2019-07-15T18:20:21.000Z",
    "today": "2021-11-08T05:00:59.465Z",
    "last_week": "2021-11-01T05:00:59.000Z"
  },
  {
    "Timestamp": "7/15/2019 16:02:11",
    "Email Address": "[email protected]",
    ,
    "Our weekly CAT newsletter": "Sure, sign me up",
    "City and Country": "",
    "Why are you interested in joining? ": "I'm building a social reforestation app",
    "What's the main thing you'd like to offer as a part of the community?": "I can offer feedback, suggestions, tips at the moment. I'm an engineer.",
    "Code of Conduct": "Yes I have read the code of conduct, and agree to follow it.",
    "parsed_timestamp": "2019-07-15T16:02:11.000Z",
    "today": "2021-11-08T05:00:59.465Z",
    "last_week": "2021-11-01T05:00:59.000Z"
  },
  // these are two which should NOT be filtered out, and are, except if I manually click through every "positive" node in the workflow
  {
    "Timestamp": "11/04/2021 8:12:43",
    "Email Address": "[email protected]",
    "Our weekly CAT newsletter": "",
    "City and Country": "",
    "Why are you interested in joining? ": "Interested into technologies of DAC and seeking possibilities of commercialization",
    "What's the main thing you'd like to offer as a part of the community?": "",
    "Code of Conduct": "Yes I have read the code of conduct, and agree to follow it.",
    "parsed_timestamp": "2021-11-14T08:12:43.000Z",
    "today": "2021-11-08T05:00:59.465Z",
    "last_week": "2021-11-01T05:00:59.000Z"
  },
  {
    "Timestamp": "11/06/2021 9:36:19",
    "Email Address": "[email protected]",
    ,
    "Our weekly CAT newsletter": "Sure, sign me up",
    "City and Country": "",
    "Why are you interested in joining? ": "Climate action in tech, low carbon infrastructure",
    "What's the main thing you'd like to offer as a part of the community?": "",
    "Code of Conduct": "Yes I have read the code of conduct, and agree to follow it.",
    "parsed_timestamp": "2021-11-06T09:36:19.000Z",
    "today": "2021-11-08T05:00:59.466Z",
    "last_week": "2021-11-01T05:00:59.000Z"
  },
]

By default, these are ALL filtered at the IF node, and end up in the Already imported do nothing node.

I think that ought to be enough to create a “test case” to see what I’m doing wrong here.

[mrchrisadams]

In fact, here’s the workflow that should be something anyone ought to be able to import and run.

I’ve redacted the sheet id in the google import but as they’re all paused anyway, this should be sufficient to see the “only go down one branch” behavior I’ve described.

[MutedJam]

Thanks a lot for sharing this example! I’ve simplified your example a bit like so:

Workflow

Indeed, when running this workflow manually with your test data, all items would fail to meet the condition defined in CAT joined in last week?. This also happens when adding a cron trigger node and waiting for the triggered execution, so no difference there:

Unfortunately, I still struggle a bit to understand the meaning of the condition you have defined in your CAT joined in last week? node. This node has a numeric condition defined, but the expressions resolve to date values, one of which also has a trailing 0:

When parsing a value such as 2019-07-15T18:20:21.000Z0 as a number JavaScript would dismiss everything after 2019 (you could try this by running something like parseFloat('2019-07-15T18:20:21.000Z0') in your browser console). This seems like a possible cause of unexpected behaviour in a workflow.

Could it be that you intended to define a date condition in your CAT joined in last week? node?

When using suitable test data, this condition would send matching items down the true branch:

Example Workflow

This works for both manual executions and triggered executions. Is this possibly what you were looking for?

[mrchrisadams]

YES! This totally fixed it - WOOHOO!

there were three things I had done wrong.

1. I did indeed have the typo with the errant [0] when making the CAT joined in last week if node. I think it might have come from me trying to access an array value and had just left it in.

2. I hadn’t realised that the strings like "2019-07-15T18:20:21.000Z" would automatically be recognised as dates and that I could use the date node like you demonstrated - I was trying to do some janky comparison between two strings hoping that a later string was higher than an earlier string.
3. When testing this, I hadn’t realised that I needed the “Start” or a Cron node to be connected to the “sample data” node in order to trigger a test run, if I wanted see how the sample data would be handled.

This made my Monday - danke!

[MutedJam]

Awesome, I am glad to hear the example helped a bit

Thanks so much for confirming!