Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flaky io.camunda.zeebe.engine.processing.multitenancy.TenantAwareTimerCatchEventTest.shouldApplyTenantToLifecycleEvents #18462

Closed
deepthidevaki opened this issue May 13, 2024 · 1 comment · Fixed by #18508
Assignees
Labels
component/zeebe Related to the Zeebe component/team kind/flake Categorizes issue or PR as related to a flaky test

Comments

@deepthidevaki
Copy link
Contributor

Summary

Try to answer the following as best as possible

  • How often does the test fail?
  • Does it block your work?
  • Do we suspect that it is a real failure?

Failures

java.lang.AssertionError: 

Expecting actual:
  [("tenant-a", ACTIVATE_ELEMENT),
    ("tenant-a", ELEMENT_ACTIVATING),
    ("tenant-a", ELEMENT_ACTIVATED)]
to contain sequence:
  [("tenant-a", ACTIVATE_ELEMENT),
    ("tenant-a", ELEMENT_ACTIVATING),
    ("tenant-a", ELEMENT_ACTIVATED),
    ("tenant-a", COMPLETE_ELEMENT),
    ("tenant-a", ELEMENT_COMPLETING),
    ("tenant-a", ELEMENT_COMPLETED)]

	at io.camunda.zeebe.engine.processing.multitenancy.TenantAwareTimerCatchEventTest.shouldApplyTenantToLifecycleEvents(TenantAwareTimerCatchEventTest.java:202)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)

Hypotheses

Logs

https://github.com/camunda/zeebe/actions/runs/9063534548
Test results for unit tests.zip

@deepthidevaki deepthidevaki added kind/flake Categorizes issue or PR as related to a flaky test component/zeebe Related to the Zeebe component/team labels May 13, 2024
@korthout
Copy link
Member

I've checked and this is another case where the timer did not trigger after traveling through time more than 5 seconds (i.e. 1 minute). It will be resolved by #18508.

github-merge-queue bot pushed a commit that referenced this issue May 27, 2024
## Description

Unflake tests that rely on time travel to trigger timers.

This was unstable because the due date checker was scheduled with a
delay, which is used to determine an actual deadline later during the
actor's scheduling of the TimerSubscription. The instability arose
because the task can be scheduled async, which means that the deadline
was calculated async as well, so it could happen that the deadline was
determined after the test had already traveled through time.

This problem is resolved by introducing a new `runAt` method, which
allows scheduling a task at a specific timestamp. When the async
scheduling is postponed until after the time traveling, the task will
trigger immediately if the timestamp is now in the past.

This changes the following modules:
- `schedule` introduces a new `runAt` method that can schedule Timer
tasks (TimerSubscription) by timestamp
- `stream-platform` introduces a new `runAt` method for the engine to
schedule tasks at a timestamp that can produce processing results
- `engine` uses the new `runAt` method to (re)schedule the
DueDateChecker

## Related issues

closes #17254
closes #10169
closes #18462
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/zeebe Related to the Zeebe component/team kind/flake Categorizes issue or PR as related to a flaky test
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants