调用 runtimeService.deleteProcessInstance 时为何流程实例未被删除？

Question

调用 `runtimeService.deleteProcessInstance()` 后流程实例未被删除，常见原因有三：一是传入了错误的 `processInstanceId`（如空值、已结束ID或根本不存在的ID），而Activiti默认不抛异常，仅静默忽略；二是该实例正处于**活动任务执行中**（如用户任务未签收/完成、服务任务正在运行），此时删除需显式指定 `deleteReason` 并启用级联删除（部分版本需配合 `cascadeDelete = true`）；三是存在**事务边界问题**——若在未提交的事务中调用删除，后续回滚将导致删除失效；此外，自定义监听器或事件处理器若抛出未捕获异常，也可能中断删除流程。建议调用前校验实例状态（`runtimeService.createProcessInstanceQuery().processInstanceId(id).singleResult() != null`），并捕获 `ActivitiObjectNotFoundException` 等关键异常，结合日志确认实际执行路径。

Answer 1

```html

一、现象层：删除无响应——表象与默认行为陷阱

调用 runtimeService.deleteProcessInstance(processInstanceId) 后流程实例“看似未被删除”，最直观表现是数据库中 ACT_RU_EXECUTION 和 ACT_HI_PROCINST 表记录依然存在，且后续查询仍可命中。根本原因在于 Activiti（6.x 及更早版本）对非法或无效 ID 的处理策略：静默忽略（no-op）而非抛异常。例如传入 null、空字符串 ""、已归档的结束实例 ID（仅存于历史表）、或根本不存在的 UUID，方法将直接返回，不触发任何 SQL DELETE 语句。

二、数据层：ID 校验失效与状态错配

• ✅ 正确做法：删除前必须双重校验
• ProcessInstance pi = runtimeService.createProcessInstanceQuery().processInstanceId(id).singleResult();
• 若 pi == null，需进一步查历史表：HistoricProcessInstance hpi = historyService.createHistoricProcessInstanceQuery().processInstanceId(id).singleResult();
• 若两者皆为 null → ID 无效；若仅 pi != null → 活动实例；若仅 hpi != null → 已结束，deleteProcessInstance() 不适用（应查归档策略）。

三、执行层：活动任务阻塞与级联删除机制

当流程实例处于活动状态（如用户任务未签收、服务任务正在执行、边界事件监听中），Activiti 默认禁止强制删除，以保障事务一致性。此时必须显式传递删除原因并启用级联：

runtimeService.deleteProcessInstance(
    processInstanceId, 
    "forced-termination-by-admin", 
    true // cascadeDelete = true（Activiti 5.22+ / 6.x 需显式传入）
);

⚠️ 注意：Activiti 7（基于 Flowable）已将该参数重构为 DeleteProcessInstanceBuilder 链式调用，旧版不传 true 将跳过子执行流、任务、变量等清理。

四、事务层：ACID 边界与传播行为失配

场景	事务配置	后果
删除操作在 @Transactional(propagation = Propagation.REQUIRED) 方法内	外层事务后续抛出未捕获异常	整个事务回滚 → 删除操作被撤销
删除操作位于 @Transactional(propagation = Propagation.REQUIRES_NEW) 独立事务	即使外层失败，删除仍生效	推荐用于关键运维操作

五、扩展层：监听器异常中断与事件钩子干扰

Activiti 支持 ExecutionListener、TaskListener 及全局 ActivitiEventListener。若任一监听器在 EVENT_NAME_DELETE 或前置事件（如 END）中抛出未捕获 RuntimeException，整个删除流程将中断——但 Activiti 不会回滚已执行的 SQL（如部分子执行删除），造成半删除脏状态。建议所有监听器包裹 try-catch 并记录 WARN 日志。

六、诊断路径：日志驱动的根因分析法

1. 开启 Activiti SQL 日志：logging.level.org.activiti.engine.impl.persistence.entity=DEBUG
2. 观察是否出现 DELETE FROM ACT_RU_EXECUTION WHERE... 语句
3. 检查 org.activiti.engine.impl.interceptor.LogInterceptor 输出，确认方法是否真正进入
4. 捕获 ActivitiObjectNotFoundException（ID 不存在）、ActivitiIllegalArgumentException（参数非法）等关键异常
5. 结合 APM 工具（如 SkyWalking）追踪跨线程/分布式上下文中的事务传播链

七、防御性编程实践：生产就绪代码模板

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void safeDeleteProcessInstance(String processInstanceId, String reason) {
    Objects.requireNonNull(processInstanceId, "processInstanceId must not be null");
    
    ProcessInstance pi = runtimeService.createProcessInstanceQuery()
        .processInstanceId(processInstanceId).singleResult();
    
    if (pi == null) {
        throw new IllegalArgumentException("No active process instance found for ID: " + processInstanceId);
    }
    
    try {
        runtimeService.deleteProcessInstance(processInstanceId, reason, true);
        log.info("Successfully deleted process instance [{}], reason: {}", processInstanceId, reason);
    } catch (ActivitiObjectNotFoundException e) {
        log.warn("Instance {} not found during deletion — may have been concurrently ended", processInstanceId);
    } catch (Exception e) {
        log.error("Unexpected error deleting process instance {}", processInstanceId, e);
        throw e;
    }
}

八、演进视角：Activiti 6 → Flowable 7 的行为迁移

graph TD
    A[Activiti 6 deleteProcessInstance] -->|隐式级联| B[需传 cascadeDelete=true]
    A -->|静默失败| C[无异常提示]
    D[Flowable 7 deleteProcessInstance] -->|Builder 模式| E[.cascade(true).reason(...).execute()]
    D -->|默认严格校验| F[传 null ID 直接抛 IllegalArgumentException]
    B --> G[升级建议：迁移至 Flowable 并启用审计日志]
    E --> G

九、监控告警：构建流程实例生命周期看板

在 Prometheus + Grafana 架构中，应采集以下指标：

• activiti_process_instance_deletion_attempts_total{result="success"}"
• activiti_process_instance_deletion_attempts_total{result="failed", cause="not_found"}"
• activiti_process_instance_orphaned_count（通过定时 SQL 扫描 ACT_RU_EXECUTION 中无父执行的孤立项）

当“失败率 > 0.5%”或“孤儿实例数突增”时，自动触发企业微信/钉钉告警，并关联最近部署的监听器变更。

十、架构反模式警示：勿在最终用户 API 中暴露裸 delete 调用

面向前端或第三方系统的接口，严禁直接透传 deleteProcessInstance。应封装为：

1. 状态机驱动：仅允许从 RUNNING → TERMINATED 迁移，拒绝 COMPLETED 实例的删除请求
2. 权限网关：校验调用方是否具备 PROCESS_INSTANCE_DELETE 权限（RBAC + 流程定义租户隔离）
3. 异步化补偿：高并发场景下转为消息队列（如 Kafka）+ Saga 模式，确保幂等与可观测性

此举将运维风险收敛至平台层，避免业务系统因误调用引发雪崩式流程积压。

```