What happened?
When an item is moved by a manual transition halfway through a scheduler run, its already-fetched candidate becomes stale. Workflow::executeTransition() correctly refuses to act, but the plugin cannot distinguish that refusal from a genuine failure.
Impact
In fireRule(), a false return takes the failure branch, which:
logs exit_code 1 with the note "permission denied, invalid transition, or stopped by a plugin"
calls markRequiresIntervention(), excluding the item from the scheduler until an admin manually clears the flag
contributes to a KNOCKOUT status, sending a failure notification email
So a benign, expected race produces a false alarm and takes an item out of automation until a human intervenes.
Suggested fix
Distinguish "transition no longer applicable" from a real failure, either by having the plugin re-verify the item's stage association before firing, or by introducing a distinct exit code for this case that does not set requires_intervention and does not count toward the failure email.
Version
5.4
Expected result
No response
Actual result
No response
System Information
No response
Additional Comments
No response
What happened?
When an item is moved by a manual transition halfway through a scheduler run, its already-fetched candidate becomes stale. Workflow::executeTransition() correctly refuses to act, but the plugin cannot distinguish that refusal from a genuine failure.
Impact
In fireRule(), a false return takes the failure branch, which:
logs exit_code 1 with the note "permission denied, invalid transition, or stopped by a plugin"
calls markRequiresIntervention(), excluding the item from the scheduler until an admin manually clears the flag
contributes to a KNOCKOUT status, sending a failure notification email
So a benign, expected race produces a false alarm and takes an item out of automation until a human intervenes.
Suggested fix
Distinguish "transition no longer applicable" from a real failure, either by having the plugin re-verify the item's stage association before firing, or by introducing a distinct exit code for this case that does not set requires_intervention and does not count toward the failure email.
Version
5.4
Expected result
No response
Actual result
No response
System Information
No response
Additional Comments
No response