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:
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.
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.
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.
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?
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?
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
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.
