Incorrect job definition for Async-after job log

[ThorbenLindhauer]

This issue was imported from JIRA:

Field	Value
JIRA Link	CAM-11328
Reporter	@garima-camunda
Has restricted visibility comments	true

---

Environment (Required on creation)

All distributions, all databases, and all supported versions.

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

As per Camunda docs, both asyncBefore and asyncAfter can be set on an activity. There is no mention of not assigning both for an activity simultaneously. Using both, we see that sometimes during the process flow when such an activity becomes active, asyncAfter Job Definition is set on the executing Job (instead of asyncBefore) which leads to inconsistency in the activity behavior on our end.

The proper job definition needs to get attached to the job during job creation.

Community forum link: https://forum.camunda.io/t/can-both-asyncbefore-and-asyncafter-be-set-on-the-same-activity/43768

Steps to reproduce (Required on creation)

Test case: https://github.com/camunda/camunda-bpm-platform/commit/b9f633cc44fa88f505905ee96b50e2a259cb9ab2

1. Create a sample process where one activity is configured with asyncBefore=true and asyncAfter=true.
2. Deploy the application and start an instance of it. The first instance usually doesn't reproduce the behavior and the job for the activity is correctly linked to the asyncBefore job definition.
3. Try to enforce that the BPMN is reloaded from the DB. The job created for the service task can now be randomly linked to the asyncAfter job definition instead of asyncBefore.

Observed Behaviour (Required on creation)

Randomly, all job entries in the ACT_HI_JOB_LOG table for the Service task activity have an asyncBefore or asyncAfter job definition associated with it.

Expected Behaviour (Required on creation)

The ACT_HI_JOB_LOG table shows entries for both asyncBefore and asyncAfter jobs consistently.

Root Cause (Required on prioritisation)

• The engine randomly picks up the job definitions from the database for a given processDefinitionId and sets the first available job definition (asyncBefore or asyncAfter in this case) to the jobDeclaration.
• BpmnDeployer, assigning either asyncBefore or asyncAfter.
• A comment mentions that ‘There can be only one job definition per activity and type’. In this case, however, both asyncBefore and asyncAfter will be of type ‘async-continuation’ and linked to the activity. Thus, this assumption is wrong.

Solution Ideas

• Additionally, match job declaration to job definition by job configuration.
  • jobDefinitionEntity.getJobConfiguration().equals(jobDeclaration.getJobConfiguration())

Hints

Links

• is depended on by https://jira.camunda.com/browse/SUPPORT-13814
• is related to https://jira.camunda.com/browse/SUPPORT-6990

Breakdown

### Main & Backport PR
- [ ] https://github.com/camunda/camunda-bpm-platform/pull/4032
- [ ] https://github.com/camunda/camunda-bpm-platform-maintenance/pull/1162
- [ ] https://github.com/camunda/camunda-bpm-platform-maintenance/pull/1163

Dev2QA handover

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

Old ticket description

What are the steps to reproduce your problem? * Start Spring boot starter app * Create a BPMN with a service task in which both `async-before` and `async-after` flags are checked. * Deploy the model via Modeler * Stop the engine * Start the engine * Start the process instance What is the problem? In the `ACT_HI_JOB_LOG` table, the job corresponding to `async-after` contains incorrect `JOB_DEF_CONFIGURATION_` and `JOB_DEF_ID_`. * Value of `JOB_DEF_CONFIGURATION_` is populated as `"async-before"` * Value of `JOB_DEF_ID_` corresponds to the job definition of `async-before`, instead of `async-after` What would be the expected behavior: In the `ACT_HI_JOB_LOG` table, the job corresponding to `async-after` should contain `"async-after"` in `JOB_DEF_CONFIGURATION_`. And `JOB_DEF_ID_` should be corresponding to the job definition of `async-after`. Hints (optional): **Links:** * is depended on by https://jira.camunda.com/browse/SUPPORT-13814 * is related to https://jira.camunda.com/browse/SUPPORT-6990

[tasso94]

Scheduled for the end of February. No customer is waiting on this. It would help the support team make investigations easier.

[mboskamp]

I will do the backport once the master PR is merged

[psavidis]

Update: Following up with the backporting as Miklas will be unavailable for the fix to make it in the upcoming patch releases.

[psavidis]

Backporting is done.