Forum Academy Marketplace Showcase Pricing Features

Strange result for :count: in workflow conditions

Hi everyone,

I’m experiencing a strange behaviour on some workflows that have been working correctly for months. I don’t know when it started but I noticed it today. I’ve been able to replicate in a test page.

So here’s what happens:
When I try to count the number of users that have a given email in order to display it in a text, everything works as expected:

=> When a user is found, the :count: is 1, else it’s 0

But when I try to do it as a condition in a workflow (for example to check if the user exists), I get “-1” as a result when it should be “0” if nothing has been found:
image

It has broken some of my workflows so I had to change the conditions from “count is 0” to “count <= 0” so everything works again.

But still, it’s not working the same way it was before, and I think it might be a bug.

Does anyone know more about this?

2 Likes

Yes, I am facing this bug in my app. Few friends filed bug reports, let wait for a fix or workaround.

Others discussion on this here:

1 Like

We’ve also had the same bug occur in our app, since yesterday evening, seemingly for an incorrect count: on conditional WFs (when count: should equal 0). We’ve filed a bug report, but glad to see there’s a temporary workaround.

1 Like

Damn, this is annoying, I thought I had messed up my WF conditions and as a result all my users on production were getting messed up by something I did.

Is the temporary fix to change it from 0 to <=0?

1 Like

I’m also having issues with counts. See this example. I have a field called Campana in users’ profiles.

image

As you can see, the debugger identifies it.

image

But when it counts it, it says 0.

image

And therefore my condition is not met.

The problem is that I have similar situations all across my app.

1 Like

@emmanuel @josh

2 Likes

I have the same problem. My app menu stopped working because of this issue and the app is completely unusable. @eve, please, we need a quick asap.

My app is on “scheduled release” so not sure why I am impacted by this…

3 Likes

Same here. I had to go in and completely modify many workflows to count “less than or equal” to zero rather than “is” 0

@emmanuel @josh

Based on my bug and the ones above, it seems all “counts” are 1 less than they should be!!!

1 Like

Also on scheduled release and I think a bug fix might have been pushed but we’re not seeing it because we’re on scheduled release. Are you still seeing this issue?

1 Like

I’m curious to know how this isn’t a massively flagged issue?

The count is 0 seems to be working now, but now some other counts aren’t working.

For eg. I have a workflow that has a parameter called invoices (Data Type: Invoices) that takes a list/array. I have a WHEN condition on it that only allows this workflow to be triggered when invoices:count>= 1

I also have within this workflow, a couple of sequences that triggers when invoices:count is 1, but since this minor bug fix was released there’s been a very odd issue happening.

I tested the workflow using only 1 invoice, and the workflow commences as expected. However when it gets to the sequences where the conditions are invoices:count is 1, they fail, and my logs of this count show up as 2? Where did it get 2 from?

1 Like

Also having count issues. This is something used in so many workflows, so much is failing…

report it as a bug!

2 Likes

Just changed my app from scheduled to immediate releases and that fixed the issue for me.

2 Likes

Hit by this same issue yesterday quietly causing lots of w/f to fail. Relieved to see it’s not just me

1 Like

the same for me, corrected by bubble. I replaced all my “: count is 0” by “count <= 0”.
Good day.

1 Like

yeap I did, that’s how I heard that a fix had been released, but replied to the ticket cause my other counts stopped functioning correctly, and haven’t heard back

2 Likes

Just been reviewing all my workflows seems like it’s all working fine now

1 Like

Thank F*** for that! Changed app from Scheduled to Immediate and it seems so far to have fixed things. That was a pretty stressful time!

Thank you to everyone who submit a bug report to get that fixed

Just in case it helps, the reason we became aware of this bug is because we’d added a ‘Failsafe’ step to all of our recursive WFs. The Failsafe only fires when all of the previous steps’ conditions aren’t met, and sends us an email with a reference to the name of the WF. Then we’re able to manually restart that WF.

For example, we have a recursive WF that runs itself on a list of items ‘only when’ item count>0 (step 7), reducing the count by 1 each time, and then fires the next WF when count=0 (step 8). The Failsafe simply sends us an email ‘only when’ step 7 and step 8 are empty. In other words, one of those steps should always run and, if not, there’s sure to be a problem.

There are good posts and resources on the forum about creating API logs, which we’ve found invaluable. For example, for all of our recursive WFs, we have ‘tally’ and ‘total’ count fields in our API log, so we can see if there’s ever a difference (i.e., if a recursive WF halts/fails, tally would be less than total).

Hope that makes sense! There are others on here who are much better at describing the approach, but it’s definitely worth looking in to.

1 Like