-
Bug Report
-
Resolution: Unresolved
-
L3 - Default
-
None
-
7.17.0
-
None
Environment (Required on creation):
Any Camunda environment.
Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket):
While creating a process definition with a repeating interval and a start date (example R2/2022-07-18T09:18:00Z/PT1M), the Camunda engine will instantiate one more process instance compared to the repeating interval number specified (3 instead of 2 in the example).
Steps to reproduce (Required on creation):
Execute the test included in this PR:
https://github.com/camunda/camunda-bpm-platform/pull/1968
or the test submitted by krisdacoder:
@Test public void shouldNotExceedNumberPeriodsWithTimeCycle() throws Exception { ClockUtil.setCurrentTime(parse("19700101-00:00:00")); DurationHelper dh = new DurationHelper("R2/1970-01-01T00:30:00/PT2M"); assertEquals(parse("19700101-00:30:00"), dh.getDateAfter()); // simulate some execution time of 10 seconds ClockUtil.setCurrentTime(parse("19700101-00:30:10")); assertEquals(parse("19700101-00:31:00"), dh.getDateAfter()); // simulate some execution time of 10 seconds ClockUtil.setCurrentTime(parse("19700101-00:31:10")); assertNull("There must not be more than 2 repetitions", dh.getDateAfter()); }
or create a process definition with a repeating interval including a start date e.g., "R2/2022-07-18T09:18:00Z/PT1M".
Observed Behavior (Required on creation):
The number of process instances instantiated is equal to the number of repetitions + 1.
Expected behavior (Required on creation):
The number of process instances instantiated should be equal to the number of repetitions.
Root Cause (Required on prioritization):
This loop which calculates the next date calculates the repeats based on the start date. When the start date is part of the expression though this leads to the timer firing once when the start date is reached and then n times to match the expression of Rn repeats.
Solution Ideas (Optional):
Hints (optional):
This is the controller panel for Smart Panels app
[CAM-14772] Repeating interval with start date instantiates too often
| Assignee | New: Miklas Boskamp [ miklas.boskamp ] |
| Link | New: This issue is related to CAMTEAM-249 [ CAMTEAM-249 ] |
| Description |
Original:
h3. Environment (Required on creation):
Using camunda engine integrated in a spring boot based service. h3. Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket): While creating a process definition with a repeating interval (example R2/2022-07-18T09:18:00Z/PT1M), camunda engine will instantiate one more process instance compared to the repeating interval number specified (3 instead of 2 in the example). The problem seems to be in [[this loop|https://github.com/camunda/camunda-bpm-platform/blob/7.17.0/engine/src/main/java/org/camunda/bpm/engine/impl/calendar/DurationHelper.java#L122]|https://github.com/camunda/camunda-bpm-platform/blob/7.17.0/engine/src/main/java/org/camunda/bpm/engine/impl/calendar/DurationHelper.java#L122] responsible for evaluation the next dueDate of a repetitive time-cycle. I wrote following test in _DurationHelperTest_ that fails: {code:java} @Test public void shouldNotExceedNumberPeriodsWithTimeCycle() throws Exception { ClockUtil.setCurrentTime(parse("19700101-00:00:00")); DurationHelper dh = new DurationHelper("R2/1970-01-01T00:30:00/PT2M"); assertEquals(parse("19700101-00:30:00"), dh.getDateAfter()); // simulate some execution time of 10 seconds ClockUtil.setCurrentTime(parse("19700101-00:30:10")); assertEquals(parse("19700101-00:31:00"), dh.getDateAfter()); // simulate some execution time of 10 seconds ClockUtil.setCurrentTime(parse("19700101-00:31:10")); assertNull("There must not be more than 2 repetitions", dh.getDateAfter()); }{code} h3. Steps to reproduce (Required on creation): Create a process definition with a repeating interval. Number of repetitions should be static. h3. Observed Behavior (Required on creation): Number of process instances instantiated is equal to the number of repetitions + 1. h3. Expected behavior (Required on creation): Number of process instances instantiated should be equal to the number of repetitions. h3. Root Cause (Required on prioritization): The problem seems to be in [[this loop|https://github.com/camunda/camunda-bpm-platform/blob/7.17.0/engine/src/main/java/org/camunda/bpm/engine/impl/calendar/DurationHelper.java#L122]|https://github.com/camunda/camunda-bpm-platform/blob/7.17.0/engine/src/main/java/org/camunda/bpm/engine/impl/calendar/DurationHelper.java#L122] responsible for evaluation the next dueDate of a repetitive time-cycle. h3. Solution Ideas (Optional): h3. Hints (optional): |
New:
h3. Environment (Required on creation):
Any Camunda environment. h3. Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket): While creating a process definition with a repeating interval and a start date (example R2/2022-07-18T09:18:00Z/PT1M), the Camunda engine will instantiate one more process instance compared to the repeating interval number specified (3 instead of 2 in the example). h3. Steps to reproduce (Required on creation): Execute the test included in this PR: https://github.com/camunda/camunda-bpm-platform/pull/1968 or the test submitted by [~krisdacoder]: @Test public void shouldNotExceedNumberPeriodsWithTimeCycle() throws Exception { ClockUtil.setCurrentTime(parse("19700101-00:00:00")); DurationHelper dh = new DurationHelper("R2/1970-01-01T00:30:00/PT2M"); assertEquals(parse("19700101-00:30:00"), dh.getDateAfter()); // simulate some execution time of 10 seconds ClockUtil.setCurrentTime(parse("19700101-00:30:10")); assertEquals(parse("19700101-00:31:00"), dh.getDateAfter()); // simulate some execution time of 10 seconds ClockUtil.setCurrentTime(parse("19700101-00:31:10")); assertNull("There must not be more than 2 repetitions", dh.getDateAfter()); } or create a process definition with a repeating interval including a start date e.g., "R2/2022-07-18T09:18:00Z/PT1M". h3. Observed Behavior (Required on creation): The number of process instances instantiated is equal to the number of repetitions + 1. h3. Expected behavior (Required on creation): The number of process instances instantiated should be equal to the number of repetitions. h3. Root Cause (Required on prioritization): [This loop|https://github.com/camunda/camunda-bpm-platform/blob/0bc04bd98a97e4099996acd3bbd42f828f77b219/engine/src/main/java/org/camunda/bpm/engine/impl/calendar/DurationHelper.java#L122-L124] which calculates the next date calculates the repeats based on the start date. When the start date is part of the expression though this leads to the timer firing once when the start date is reached and then {{n}} times to match the expression of {{Rn}} repeats. h3. Solution Ideas (Optional): h3. Hints (optional): |
| Description |
Original:
h3. Environment (Required on creation):
Any Camunda environment. h3. Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket): While creating a process definition with a repeating interval and a start date (example R2/2022-07-18T09:18:00Z/PT1M), the Camunda engine will instantiate one more process instance compared to the repeating interval number specified (3 instead of 2 in the example). h3. Steps to reproduce (Required on creation): Execute the test included in this PR: https://github.com/camunda/camunda-bpm-platform/pull/1968 or the test submitted by [~krisdacoder]: @Test public void shouldNotExceedNumberPeriodsWithTimeCycle() throws Exception { ClockUtil.setCurrentTime(parse("19700101-00:00:00")); DurationHelper dh = new DurationHelper("R2/1970-01-01T00:30:00/PT2M"); assertEquals(parse("19700101-00:30:00"), dh.getDateAfter()); // simulate some execution time of 10 seconds ClockUtil.setCurrentTime(parse("19700101-00:30:10")); assertEquals(parse("19700101-00:31:00"), dh.getDateAfter()); // simulate some execution time of 10 seconds ClockUtil.setCurrentTime(parse("19700101-00:31:10")); assertNull("There must not be more than 2 repetitions", dh.getDateAfter()); } or create a process definition with a repeating interval including a start date e.g., "R2/2022-07-18T09:18:00Z/PT1M". h3. Observed Behavior (Required on creation): The number of process instances instantiated is equal to the number of repetitions + 1. h3. Expected behavior (Required on creation): The number of process instances instantiated should be equal to the number of repetitions. h3. Root Cause (Required on prioritization): [This loop|https://github.com/camunda/camunda-bpm-platform/blob/0bc04bd98a97e4099996acd3bbd42f828f77b219/engine/src/main/java/org/camunda/bpm/engine/impl/calendar/DurationHelper.java#L122-L124] which calculates the next date calculates the repeats based on the start date. When the start date is part of the expression though this leads to the timer firing once when the start date is reached and then {{n}} times to match the expression of {{Rn}} repeats. h3. Solution Ideas (Optional): h3. Hints (optional): |
New:
h3. Environment (Required on creation):
Any Camunda environment. h3. Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket): While creating a process definition with a repeating interval and a start date (example R2/2022-07-18T09:18:00Z/PT1M), the Camunda engine will instantiate one more process instance compared to the repeating interval number specified (3 instead of 2 in the example). h3. Steps to reproduce (Required on creation): Execute the test included in this PR: https://github.com/camunda/camunda-bpm-platform/pull/1968 or the test submitted by [~krisdacoder]: {code:java} @Test public void shouldNotExceedNumberPeriodsWithTimeCycle() throws Exception { ClockUtil.setCurrentTime(parse("19700101-00:00:00")); DurationHelper dh = new DurationHelper("R2/1970-01-01T00:30:00/PT2M"); assertEquals(parse("19700101-00:30:00"), dh.getDateAfter()); // simulate some execution time of 10 seconds ClockUtil.setCurrentTime(parse("19700101-00:30:10")); assertEquals(parse("19700101-00:31:00"), dh.getDateAfter()); // simulate some execution time of 10 seconds ClockUtil.setCurrentTime(parse("19700101-00:31:10")); assertNull("There must not be more than 2 repetitions", dh.getDateAfter()); } {code} or create a process definition with a repeating interval including a start date e.g., "R2/2022-07-18T09:18:00Z/PT1M". h3. Observed Behavior (Required on creation): The number of process instances instantiated is equal to the number of repetitions + 1. h3. Expected behavior (Required on creation): The number of process instances instantiated should be equal to the number of repetitions. h3. Root Cause (Required on prioritization): [This loop|https://github.com/camunda/camunda-bpm-platform/blob/0bc04bd98a97e4099996acd3bbd42f828f77b219/engine/src/main/java/org/camunda/bpm/engine/impl/calendar/DurationHelper.java#L122-L124] which calculates the next date calculates the repeats based on the start date. When the start date is part of the expression though this leads to the timer firing once when the start date is reached and then {{n}} times to match the expression of {{Rn}} repeats. h3. Solution Ideas (Optional): h3. Hints (optional): |
| Assignee | Original: Miklas Boskamp [ miklas.boskamp ] | New: Thorben Lindhauer [ thorben.lindhauer ] |
| Assignee | Original: Thorben Lindhauer [ thorben.lindhauer ] | New: Tobias Metzke-Bernstein [ tobias.metzke ] |
| Assignee | Original: Tobias Metzke-Bernstein [ tobias.metzke ] | New: Miklas Boskamp [ miklas.boskamp ] |
| Assignee | Original: Miklas Boskamp [ miklas.boskamp ] | New: Tobias Metzke-Bernstein [ tobias.metzke ] |
Hey krisdacoder. thanks for reaching out to us with this bug report. Great to see that you already wrote a test to reproduce the issue. This always helps with the investigation.
I can confirm, that this is not expected and will be treated as a bug. When specifying a start date in the timer configuration like R2/1970-01-01T00:00:00/PT10S we expect the timer to fire two times. This is also documented with an example: https://docs.camunda.org/manual/latest/reference/bpmn20/events/timer-events/#timer-start-event
If you are interested in fixing this bug, this would be very much appreciated. Just let us know here in the ticket. We can help you with questions if you need any assistance. Otherwise, I will be forwarding the ticket for prioritization. I can not say when we will be able to work on it though.
Best,
Miklas