Describe the bug
If you create a simple trigger long before is later scheduled, the first fire time is computed as the StartTimeUtc, which is not correct. This causes problems with repetitions (if any) because the nextFireTimeUtc is also not calculated correctly.
Version used
I have tested this with v3.10.0
To Reproduce
You can see a working example here:
https://github.com/ismdiego/quartz_simple_trigger_reuse
There is one job defined, that delays for 1 second.
There are two triggers for the same job:
- trigger1 (repeats forever, each 10 seconds)
- trigger2 (repeats 3 times, each 2 seconds) -> scheduled after trigger1 completes
You can see that the second repetition of the trigger2 starts before it must.
Expected behavior
- trigger1 fires at 00:00
- trigger1 completes at 00:01
- trigger2 fires, first repetition at 00:01
- trigger2 second repetition at 00:03 -> error, it fires at 00:02 (2 seconds after 00:00)
- trigger2 third repetition at 00:05 -> error, it fires at 00:04 (2 seconds after 00:02)
- trigger1 fires at 00:10
- repeat indefinitely... the next repetitions work well
Maybe this is not the best practice (to create a trigger and a long time afterwards schedule it) but I think the system should behave as expected.
Additional context
I have programmed a quick fix and it works for my case. It also passes all the Unit tests defined in Quartz.Tests.Unit. I attach the git patch that can be applied over the v3.10.0 tag:
0001-Fixes-2455.patch
Describe the bug
If you create a simple trigger long before is later scheduled, the first fire time is computed as the StartTimeUtc, which is not correct. This causes problems with repetitions (if any) because the nextFireTimeUtc is also not calculated correctly.
Version used
I have tested this with v3.10.0
To Reproduce
You can see a working example here:
https://github.com/ismdiego/quartz_simple_trigger_reuse
There is one job defined, that delays for 1 second.
There are two triggers for the same job:
You can see that the second repetition of the trigger2 starts before it must.
Expected behavior
Maybe this is not the best practice (to create a trigger and a long time afterwards schedule it) but I think the system should behave as expected.
Additional context
I have programmed a quick fix and it works for my case. It also passes all the Unit tests defined in Quartz.Tests.Unit. I attach the git patch that can be applied over the v3.10.0 tag:
0001-Fixes-2455.patch