flowable/flowable-engine · error · ActivitiException

this activity doesn't accept signals

Error message

this activity doesn't accept signals

What it means

FlowNodeActivityBehavior.signal() is the default implementation for activities that do not react to signals. Concrete behaviors that accept signals override it; the base version throws ActivitiException to signal misuse. Hitting it means the engine (or custom code) delivered a signal to an activity that cannot handle one.

Solutions

1. Override signal(signalName, signalData) in your custom behavior and implement leave() from it
2. Use an activity type designed as a wait state (e.g. receive task, user task) if external signaling is required
3. Fix process flow so the execution does not stop on a non-wait-state activity

Example fix

// before
class MyBehavior extends FlowNodeActivityBehavior { public void execute(ActivityExecution e) { /* wait */ } }
// after
class MyBehavior extends FlowNodeActivityBehavior {
  public void execute(ActivityExecution e) { /* wait */ }
  @Override public void signal(ActivityExecution e, String n, Object d) { leave(e); }
}

// Only signal executions parked on wait states that accept signals
String activityId = runtimeService.getActiveActivityIds(executionId).get(0);
if (!SIGNAL_CAPABLE_ACTIVITY_IDS.contains(activityId)) throw new IllegalStateException("activity does not accept signals");

try { runtimeService.signal(executionId); }
catch (ActivitiException e) { if (e.getMessage().contains("doesn't accept signals")) { convertToReceiveTaskOrFixModel(); } throw e; }

When it happens

Trigger: Calling execution.signal(signalName, data) or runtimeService.signal(executionId) while the current wait-state activity's behavior is the base FlowNodeActivityBehavior (e.g. a plain service task wrongly left in a wait state, or custom behavior not overriding signal).

Common situations: Custom ActivityBehavior extending FlowNodeActivityBehavior without overriding signal while using it as a wait state; signaling an execution parked on a non-wait-state node due to a modeling bug.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• Cannot throw process-instance scoped signal, since the…
• Could no handle signal: no start activity found with id
• Could not find matching FlowElement for " +…
• Could not handle signal: no process instance started
• Could not handle signal: process definition with id: " +…

AI-assisted analysis of flowable/flowable-engine@d6d39ce1c6 (2026-09-11). Data as JSON: /api/errors/5ef87d6cc2cfacf2. Report an issue: GitHub.

Appendix: source

Thrown at modules/flowable5-engine/src/main/java/org/activiti/engine/impl/bpmn/behavior/FlowNodeActivityBehavior.java:53

    public void execute(DelegateExecution execution) {
        leave((ActivityExecution) execution);
    }

    /**
     * Default way of leaving a BPMN 2.0 activity: evaluate the conditions on the outgoing sequence flow and take those that evaluate to true.
     */
    protected void leave(ActivityExecution execution) {
        bpmnActivityBehavior.performDefaultOutgoingBehavior(execution);
    }

    protected void leaveIgnoreConditions(ActivityExecution activityContext) {
        bpmnActivityBehavior.performIgnoreConditionsOutgoingBehavior(activityContext);
    }

    @Override
    public void signal(ActivityExecution execution, String signalName, Object signalData) throws Exception {
        // concrete activity behaviours that do accept signals should override this method;
        throw new ActivitiException("this activity doesn't accept signals");
    }

}

View on GitHub (pinned to d6d39ce1c6)