Zombie records in act_hi_% tables in case of process start-failure

ENV: openjdk version “1.8.0_131”, springboot 1.5.8-RELEASE, MySQL 5.7.20 InnoDB, camunda 7.7.0 with ProcessEngineConfiguration.HISTORY_FULL

We have a unique constraint in table act_ru_execution on (proc_def_id_,business_key_,tenant_id_). Of course we did this on our own. Purpose is to limit to one process instance for a given business key within one tenant. It actually works fine, until we investigated the act_hi_procinst table. In case of a fail start because of this unique constraint violation, a record is written into this table with state_ set to ACTIVE. Records also found in act_hi_varinst, act_hi_detail, act_hi_actinst, act_hi_identitylink, act_hi_taskinst and act_au_authorization. It looks like a batch update operation. Failure happened at inserting ExecutionEntity. Is it not supposed to rollback the changes in other tables? No transaction semantic changes on our side. We can reproduce this behaviour.

Or HISTORY_FULL means everything will be recorded. In this case the state_ should be set as something other than ACTIVE, right?


The stacktrace:
org.camunda.bpm.engine.ProcessEngineException: ENGINE-03004 Exception while executing Database Operation 'INSERT ExecutionEntity[166611]' with message '
### Error updating database. Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry 'edit_entity:2:142233-entity' for key 'ACT_UNIQ_RU_BUS_KEY'
### The error may involve org.camunda.bpm.engine.impl.persistence.entity.ExecutionEntity.insertExecution-Inline
### The error occurred while setting parameters
### SQL: insert into xx.ACT_RU_EXECUTION ( ID_, PROC_INST_ID_, BUSINESS_KEY_, PROC_DEF_ID_, ACT_ID_, ACT_INST_ID_, IS_ACTIVE_, IS_CONCURRENT_, IS_SCOPE_, IS_EVENT_SCOPE_, PARENT_ID_, SUPER_EXEC_, SUPER_CASE_EXEC_, CASE_INST_ID_, SUSPENSION_STATE_, CACHED_ENT_STATE_, SEQUENCE_COUNTER_, TENANT_ID_, REV_ ) values ( ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, 1 )
### Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry 'edit_entity:2:142233-entity' for key 'ACT_UNIQ_RU_BUS_KEY''. Flush summary:
[
INSERT HistoricVariableInstanceEntity[166613]
more hi varinst
INSERT AuthorizationEntity[166631]
INSERT HistoricVariableUpdateEventEntity[166619]
more hi var update event entity
INSERT HistoricTaskInstanceEventEntity[166628]
INSERT HistoricProcessInstanceEventEntity[166611]
INSERT HistoricIdentityLinkLogEventEntity[166630]
INSERT HistoricActivityInstanceEventEntity[StartEvent_199pk0x:166615]
INSERT HistoricActivityInstanceEventEntity[ut_01_edit_entity:166623]
INSERT ExecutionEntity[166611]
INSERT TaskEntity[166628]
INSERT ByteArrayEntity[166612]
more for task entity, var inst
INSERT IdentityLinkEntity[166629]
]
at org.camunda.bpm.engine.impl.db.EnginePersistenceLogger.flushDbOperationException(EnginePersistenceLogger.java:115)
at org.camunda.bpm.engine.impl.db.entitymanager.DbEntityManager.flushDbOperationManager(DbEntityManager.java:305)
at org.camunda.bpm.engine.impl.db.entitymanager.DbEntityManager.flush(DbEntityManager.java:281)
at org.camunda.bpm.engine.impl.interceptor.CommandContext.flushSessions(CommandContext.java:203)
at org.camunda.bpm.engine.impl.interceptor.CommandContext.close(CommandContext.java:132)
at org.camunda.bpm.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:113)
at org.camunda.bpm.engine.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTransactionInterceptor.java:42)
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:133)
at org.camunda.bpm.engine.spring.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:40)
at org.camunda.bpm.engine.impl.interceptor.ProcessApplicationContextInterceptor.execute(ProcessApplicationContextInterceptor.java:66)
at org.camunda.bpm.engine.impl.interceptor.CommandContext.flushSessions(CommandContext.java:203)
at org.camunda.bpm.engine.impl.interceptor.CommandContext.close(CommandContext.java:132)
at org.camunda.bpm.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:113)
at org.camunda.bpm.engine.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTransactionInterceptor.java:42)
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:133)
at org.camunda.bpm.engine.spring.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:40)
at org.camunda.bpm.engine.impl.interceptor.ProcessApplicationContextInterceptor.execute(ProcessApplicationContextInterceptor.java:66)
at org.camunda.bpm.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:30)
at org.camunda.bpm.engine.impl.ProcessInstantiationBuilderImpl.executeWithVariablesInReturn(ProcessInstantiationBuilderImpl.java:162)
at org.camunda.bpm.engine.impl.ProcessInstantiationBuilderImpl.executeWithVariablesInReturn(ProcessInstantiationBuilderImpl.java:133)

Are you able to reproduce this in a test case that you could share via github? When working correctly, a failing engine command should rollback the entire transaction so no changes should be persisted.

Cheers,
Thorben

It’ll take a while, but we’ll come back with an example repo asap.

1 Like