Fix CRON timer wrongly computes after date when L expression is used

[joaquinfelici]

Environment (Required on creation)

Any.

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

A client is experiencing an issue where his start timer event with a Cron expression is creating infinite jobs instead of the ones that match the expression. The reason behind it seems to be an bug in the CronExpression getTimeAfter algorithm, only for expressions containing "L-X" meaning X days before the end of the month. For example 0 0 12 L-27 * ? which means 27 days before the end of each month at 12:00:00.

The CronExpression class is interpreting the expression correctly, but when getting the "after time", meaning the next date that matches the expression, it's not working and returning the date for the current month even if it's in the past.

Steps to reproduce (Required on creation)

1. Deploy a process definition with a start event timer with a Cron expression containing the L-X syntax, for example 0 0 12 L-27 * ?.
2. The X should be greater than the remaining days in the current month to reproduce the behavior.

Observed Behavior (Required on creation)

The computed execution date will be in the past, and this will trigger the execution multiple times instead of once.

Expected behavior (Required on creation)

The computed execution should always be in the future. If the target date has already passed for the current month, then it should be created once for the following month.

Root Cause (Required on prioritization)

There's a bug in the CronExpression getTimeAfter algorithm.

Solution Ideas

• Either fix the bug by taking inspiration of the latest release of Quartz Library. If we follow this approach, take this bug into account (and it's correction).
• Or directly use their library as a dependency.

Hints

Created a pull request that contains:

• The expected behavior in the test additions.
• A POC for the CronExpression class.

Links

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

Breakdown

Pull Requests

• test(engine): add test for cron expressions #5285
• chore(engine): switch to cron-utils #5288
• chore(docs): switch from quartz to spring cron expressions camunda-docs-manual#1803
• chore(update): adjust cron expression paragraph camunda-docs-manual#1821

Dev2QA handover

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

[yanavasileva]

Evaluation

1. Copy/paste CronExpression with latest changes from quartz library
   • POC: poc(engine): copy/paste from quartz #5287
   • pros
     • easy to implement
     • code remains with us so we can be flexible to cherry-pich bug and vulnerability fixes
   • cons
     • if there's a bug found in the future, we need to picked it manually again
     • there's still a bug for a leap year
2. Use quartz library
   • POC: poc(engine): use quartz library #5286
   • pros
     • only one vulnerability in the past releases; Optimize uses it. If vulnerability is detected, we can check if it's applicable for both components.
     • apache 2
     • straight forward to use/implement and no breaking changes?
   • cons
     • latest changes are not released
     • no release cycle, if there's an issue we will depend on them to release a patch
3. use cron-util library
   • POC: chore(engine): switch to cron-utils #5288
   • pros
     • has the fix for L expression including leap year
     • zeebe uses it
     • more functionality, we have been discussed to adopt the library before as customer wants to use pipe-separation: https://jira.camunda.com/browse/SUPPORT-21896
       • features: https://github.com/jmrozanec/cron-utils#:~:text=issue%20%233-,Features,-Create%20arbitrary%20cron
     • apache 2
   • cons
     • 1 c and 1 h vulnerability in the past https://security.snyk.io/package/maven/com.cronutils%3Acron-utils
     • not sure if our existing test coverage is sufficient to understand if there's a breaking changes in the behaviour
       • 7th optional field for year is not supported
4. change our CronExpression to extend quartz CronExpression
   • pros
     • remain flexibility to overwrite methods in case of bugs or vulnerabilities
     • easy to implement
   • cons
     • current issue is in private method, we will need to overwrite whole main #getTimeAfter() to fix the current issue