My teammate and I have a workflow that contains an 'If/Else' box.
Since we applied the latest patches (3.144 - 3.178), this condition isn't working as it used to.
We can see the workflow falls into the 'Else' condition but the actions/branches from both the 'If' and the 'Else' box are running.
Previously, it would only action the boxes linked to either condition depending on which applied at the time of the workflow run.
Is this a potential bug since the latest release?
Or is there a new configuration we need to add to allow the 'If/Else' to only run one of the branches based on the condition?
We have unfortunately.
We've not recreated the whole workflow but we have tried deleting and recreating the 'If/Else' block
Also have tried switching up the conditions but it's still running both conditions instead of just the one
Hi @ally.b,
Can you share a screenshot or 2 of your 'If/Else' block as well as a sample of the data? Also, do you have a sample of the old data (when the if/else block worked)?
Of course, this is the 'If/Else' condition. On the current run it falls into the Else because the API in a previous block has found data.
The following blocks on the Else generate an email and send it out to a distribution list. The 'If' generates a slightly different email and sends out to the same list.
What we're getting now is two emails everytime this workflow runs whereas before we only got one.
Identified in the run history that both blocks following the 'If/Else' are running
Sorry, can we get a bigger picture In the first screenshot I see SG_Check_if_API_Return... and don't see the names of the 2 blocks linked to the if/else block. Same with the log run. I see Check_if_API_Return... but not SG_Check_if_API_Return... I am assuming these are different. After the Check_if_API_Return... I am seeing a block No BAUFailures... being skipped so this seems to be working. It might be handy to see that block as well.
So sorry! That was a test block. This is the 'Check_if_API_Return...' block in use
In previous runs (before applying the patches) 'No BAUFailures...' doesn't attempt to run at all. What's happening now is it attempts to run that block then skips it but carries on with the rest of the subsequent blocks.
Here's a wider picture of this part of the workflow
Are you able to attend Office Hours in about 3 hours? Sign up link and discord links are in the post.
It would be easier to diagnose live and there are always 2-3 Retool engineers there. If it is a version issue, they will escalate for you. If it is a code change they will point you in the right direction.
I can help in about 6 hours if still needed.
Unfortunately not. Right now anyways they are 11-12 pst Tuesdays and Thursdays, so a little late for you.
@Darren , @Tess are you able to have a look into this and see it is a bug? It seems the if/else block was working on a previous version. Unfortunately, neither of us will be able to make it to Office Hours today.
later on in the workflow do those 2 branches merge at 1 block? like does the 'response' block reference both NoBAUFailuresEmailBody and BAUFailurEmailBody? If so, it might think that those blocks need to be resolved before running the response, even if only 1 of the blocks ends up being used.
when the code gets to the red circle, we may know it evaluates to false, but JS might not. In order for it to know it needs to evaluate SendEmail.data, and if the SendEmail block requires results from EmailSubject and NoBAUFailuresEmailBody it might need to evaluate both of those first. after evaluating them, it can then finish evaluating what's in the red circle where it realizes it can be skipped.... resulting in the blocks being ran, but skipped immediately after.
its just a guess though. If this is the case though, the solution would be to split that last block into 2 seperate ones, so that both pathways stay seperate
Whilst the If/Else block is still not functioning as expected (running both conditions), the latest suggestion gave me an idea to test.
Our workflow wasn't merging back into one block, the two branches were running in parallel with the intention that only one branch would run through to the end and send an email.
This morning I've tested merging the workflow back together before sending an email and after a few tweaks I've been able to get a resolution!
As we know both conditions in the If/Else block run, I've added a final transformer that will use the 'BAUFailuresEmailBody' if 'NoBAUFailuresEmailBody' returns a null value (which it does when the two branches run in parallel and the former returns legitimate data).
The data from that final transformer has been plugged into the Email API block of which there's now only one.
After testing, we're getting just the one email now with the right data in it and have tested the negative to ensure that if 'NoFailuresEmailBody' returns legitimate data then that is used in the email body instead.
Again this hasn't resolved the issue of the If/Else block running both conditions but it's a viable workaround for us and correcting the symptom of us getting two emails for every trigger of this workflow.
Really appreciate your help and guidance on this one! We're relatively green in our Retool workflow use so hadn't thought of merging the branches back together!
So far, I haven't been able to reproduce this issue or track down any known bugs that seem related