fix: quick fix for a timer bug

[koevskinikola]

Description

Fixed-rate timers don't play nicely with backward time adjustments. For fixed rate timers, an execution is scheduled for ex. 5 seconds in the future. When that execution runs, it schedules the next one, etc. However, when traveling backwards in time, the next scheduled execution never triggers.

The issue needs to be fixed properly in Zeebe. A temporary workaround is to adjust the tests with a future date time.

Related issues

related to #1230

Definition of Done

Not all items need to be done depending on the issue and the pull request.

Code changes:

• The changes are backwards compatibility with previous versions
• If it fixes a bug then PRs are created to backport the fix

Testing:

• There are unit/integration tests that verify all acceptance criterias of the issue
• New tests are written to ensure backwards compatibility with further versions
• The behavior is tested manually

Documentation:

• Javadoc has been written
• The documentation is updated

[github-actions]

Test Results

 50 files  + 46   50 suites  +46   1m 33s ⏱️ + 1m 33s
138 tests +126  138 ✅ +127  0 💤 ±0  0 ❌  - 1 
438 runs  +434  438 ✅ +438  0 💤 ±0  0 ❌  - 4 

Results for commit 14318b8. ± Comparison against base commit 747e0d3.

♻️ This comment has been updated with latest results.

[remcowesterhoud]

I merged my branch to add the authorization valuetype to the logger into this branch to make sure the CI doesn't fail on this and we can actually merge it.

The only relevant change in this PR is the commit @koevskinikola made.

[megglos]

@koevskinikola @remcowesterhoud the tests still fail on main and also failed on the merge queue 🤔 can you take another look? CC @nicpuppa

[nicpuppa]

Since this failures are blocking the alpha release, I'm in favour of disable the failing tests on the alpha release branch. What's the impact from an user perspective ?

@remcowesterhoud @koevskinikola

[koevskinikola]

@megglos I'm having another look right now. @nicpuppa is it okay if I timebox the investigation for 30mins? After that we can ignore the tests so that we can release ZPT.

From what Lena explained, the issue is more on the Zeebe side, i.e. how the process schedule service works (src) and we'll need more time to fix that.

[koevskinikola]

It seems like the TimerTest is failing only on the Testcontainers extension "variant". I had some issues with my Docker setup so I didn't have time to dig too deeply, but the Testcontainers extension is using a ContainerizedEngine implementation, and we use the InMemoryEngine implementation of the engine in the in-memory extension. There might be some differences in these implementations on how we handle the time jumps which leads the Testcontainers variant to still fail.

@nicpuppa I'll disable the Testcontainers variant of the TimerTest so that the release can resume. I'll raise a PR soon, for some reason the JUnit 5 @Disabled annotation is not picked up and the test continues to run locally.

[nicpuppa]

Thanks @koevskinikola, please open a PR from the release branch 🙏