Hello colleagues. I've encountered a persistent issue in our LogicGate Risk Cloud implementation that has stalled several critical workflows, and I'm hoping to crowdsource some diagnostic approaches. The core problem is that workflows consistently become stuck in a 'pending' state immediately after a conditional routing step, with no subsequent progression or error generation. The automation simply halts.
After reviewing the audit logs and the workflow's JSON definition, I've isolated the scenario to a branch where the condition evaluates to `false`. Interestingly, workflows where the same condition evaluates to `true` proceed without issue. This suggests the bug lies not in the condition logic itself, but in the system's handling of the 'false' branch's target node.
Here is a simplified anonymized schema of the problematic step configuration, as exported from the platform's API:
```json
{
"nodeType": "CONDITION",
"id": "condition_456",
"config": {
"expression": "{{trigger.payload.risk_score}} > 75",
"trueTarget": "node_escalation_approval",
"falseTarget": "node_standard_review"
}
}
```
The data payload confirms that `risk_score` is often 50, which should route to `node_standard_review`. However, the instance remains 'pending' on `condition_456`.
My investigation thus far has involved:
* **Data Validation:** I've confirmed the incoming data type for `risk_score` is integer, not a string, eliminating a common type-coercion pitfall.
* **Target Node State:** The `node_standard_review` is active and properly configured with valid assignees and permissions.
* **API Analysis:** Calls to the LogicGate API for the stalled instances show a `statusReason` of `"AWAITING_NEXT_NODE"`, which is unhelpfully generic.
My primary hypothesis is that there is an undocumented constraint or a silent validation failure occurring on the target node when it is invoked via a 'false' branch. Have any of you experienced similar behavior? Specifically:
* Is there a known issue with conditional routing to nodes that have certain subsequent connectors or specific field configurations?
* Has anyone devised a diagnostic SQL query to cross-reference stalled instance IDs against workflow version changes or permission sets? I'm currently joining the `audit_log` and `workflow_instances` tables in our data warehouse to look for patterns.
* Could this be a concurrency or locking issue within the platform? The 'pending' state suggests it's waiting for a resource that never becomes available.
Any insights, shared experiences, or even your own diagnostic queries would be invaluable. I'll update this thread with any findings from our side.
- dan
Garbage in, garbage out.
Interesting! I had something similar happen with a Zapier condition last month. My workflow hung when the condition was false, just like you described.
Did you check if the "node_standard_review" target step even exists and is active? Sometimes I've accidentally deactivated or deleted the next step, so the workflow just stops because it has nowhere to go.
Thanks!
Check the permissions on the `node_standard_review` step. I've seen workflows hang when the false branch routes to a step that the initiating user or system context doesn't have execute rights for. The audit log might show a silent permission failure.
YAML all the things.
Oh that's a tricky one. If the workflow only hangs on the false branch, that really does point to something wrong with that specific target node. The permissions idea from the last post is a good angle.
But what if the `node_standard_review` step has a pre-condition or a different trigger setting that isn't being met? Maybe it's waiting for some data that isn't being passed when coming from the false route? Just a thought from my limited experience.
Still learning