Exception in History-Cleanup produces ByteArray without removal time

[danielkelemen]

Environment (Required on creation)

Reported in 7.18.5-ee. Also reproduced in latest version.

Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket)

Exceptions during history cleanup produce a job log with a corresponding ByteArray containing the stack trace. When the historyCleanupJobLogTimeToLive is configured this job log contains the correct removalTime. However, the stack trace byte array entity does not have the removalTime set.
As a consequence, these byte arrays will remain in the database and won't get cleaned up.

Steps to reproduce (Required on creation)

1. Configure history cleanup with historyCleanupJobLogTimeToLive=1
2. Force an exception during history cleanup
   • Set a breakpoint in HistoricProcessInstanceManager.deleteHistoricProcessInstancesByRemovalTime
   • Override the commandContext to null
3. Look up the created ACT_HI_JOB_LOG and ACT_GE_BYTEARRAY records. The removalTime is not set for the byte array which means it won't be cleaned up.

Observed Behavior (Required on creation)

The history cleanup stack trace byte array has no removalTime set.
The record will not get cleaned up from the database.

Expected behavior (Required on creation)

The history cleanup stack trace byte array has removalTime set.
The record will get cleaned up from the database.

Root Cause (Required on prioritization)

The DefaultHistoryEventProducer skips setting the removalTime of the byte array when strategy end is defined. This works fine with job log byte arrays that are related to process instances as they will get updated later when the corresponding PI has ended.
However, history cleanup job log has no process instance relation so their byte arrays will remain in the database.

Solution Ideas

If the HistoricJobLogEventEntity has no processInstanceId, the byte array could inherit the same removalTime as the job log entity, regardless of the removal time strategy:

if (isHistoryRemovalTimeStrategyStart() || event.getProcessInstanceId() == null) {
  byteArray.setRemovalTime(event.getRemovalTime());
}

In DefaultHistoryEventProducer.

Hints

Links

• https://jira.camunda.com/browse/SUPPORT-16389

Breakdown

Dev2QA handover

• Does this ticket need a QA test and the testing goals are not clear from the description? Add a Dev2QA handover comment

[ThorbenLindhauer]

I wonder if the if statement is needed at all in DefaultHistoryEventProducer#createHistoricJobLogFailedEvt. The same condition exists already in #initHistoricJobLogEvent, so if the removal time strategy is end and the event belongs to a process instance, the removal time will be null and we could "copy" that null value to the byte array, too (just from reading the code; might misunderstand this).

So maybe this can also be fixed by just removing the condition when setting the byte array removal time. Think about it another way: The job log event and the byte array should probably never have different removal times. So just copying the job log's removal time over unconditionally sounds reasonable.

[tmetzke]

Review hints:

• Code changes look good, I only added some smaller suggestions.
• Please don't forget to backport this as indicated by the issue labels.

[yanavasileva]

Assigning for a backport review.

[yanavasileva]

Backport review: done.