[UI] Triggers page shows next execution date inconsistently for Schedule triggers

[sebastianknopf]

Describe the issue

I'm facing some trouble with Schedule triggers in Kestra. My kestra instance (currently v0.19.12) is running as docker container. Everythin works, but the Schedule triggers with cron property do not work.

For testing, I created the following flow:

id: vpe_trigger_test
namespace: vpe.test
tasks:
  - id: hello
    type: io.kestra.plugin.core.log.Log
    message: Hello World!
triggers:
  - id: trigger
    type: io.kestra.plugin.core.trigger.Schedule
    cron: "* * * * *"

Regarding to the cron expression, I expect the trigger to run the flow once per minute. After saving the flow in the UI and changing to the tab Triggers, I can see the trigger but with wrong execution time:

When saving the flow at 15:27, I would expect it to start at 15:28 next time with this cron expression. Sometimes, the next execution timestamp increases in steps of around 10min with every time I refresh the whole page. Sadly, I cannot reproduce this exactly.

However, even if the next exection time is exceeded, I cannot find an additional execution which is triggered by the Schedule trigger.

Any ideas, whats going wrong here?

Environment

• Kestra Version: 0.19.12

[anna-geller]

hmm, I wasn't able to reproduce. Can you try removing the trigger from your code, saving the flow, then re-adding the trigger with a different ID and an explicit cron definition for every minute like so?

id: vpe_trigger_test
namespace: vpe.test

tasks:
  - id: hello
    type: io.kestra.plugin.core.log.Log
    message: Hello World!

triggers:
  - id: schedule
    type: io.kestra.plugin.core.trigger.Schedule
    cron: "*/1 * * * *"

btw glad to see you use the German translation 🇩🇪 let me know if you find any translation mistakes

[sebastianknopf]

This is pretty interesting... After updating my staging environment to v 0.21.2, everything works like a charm. Your adapted snippet as well as my original snippet.

I'll try to update the production environment tomorrow, then I'll report about what changed.

BTW: The german translation works absolutely fine, especially in v 0.21.2! Thank you for that!

[anna-geller]

Great to hear! keep us posted and feel free to close the issue directly if you no longer see any problem here

[sebastianknopf]

I updated the production environment to v0.21.2 too, but still facing the issue. After changing the flow to your example, the same behaviour again: Every time I refresh the page, the 'next execution time' is set a few minutes later until a difference from exactly one hour is reached. After reaching this hour, the 'next execution time' is incremented with every minute, but in a difference of one hour.

Could that be, that there's an issue with dayligh saving time between the hosting server and docker here? Maybe also with the MySQL-Server running in background?

Kestra is configured to our German timezone Europe/Berlin in the settings:

[sebastianknopf]

Additionally, I've found another interesting information: The production server is running itself in Europe/Berlin

Where as the staging server is running in UTC:

[anna-geller]

ahh I think I know what it is

scheduling is fully decoupled from the UI timezone configured in Settings

so to use the German timezone in scheduling, you would need to explicitly add timezone info, otherwise it will do scheduling in UTC:

id: vpe_trigger_test
namespace: vpe.test

tasks:
  - id: hello
    type: io.kestra.plugin.core.log.Log
    message: Hello World!

triggers:
  - id: schedule
    type: io.kestra.plugin.core.trigger.Schedule
    cron: "*/1 * * * *"
    timezone: Europe/Berlin

sorry, I should have mentioned that timezone property sooner

this should resolve the confusion

[sebastianknopf]

Sadly, still facing the same issue... After adding the timezone property in the flow, the next exectuion time is shown in German timezone, but still wrong at all. With every refresh of the page, the next execution time is increased:

See following screenshots:

These two screenshots were just a few minutes apart, without changing anything in the flow definition or doing any other action in Kestra. What I noticed is, that the update timestamp also seems to be increased, exactly to the timestamp when I refreshed the page. I could reproduce this behaviour with a third approach at 06:55. Maybe something goes wrong here...?

For the next test, I will set the timezone of the hosting machine back to UTC, as in the staging environment. Maybe there's a problem between timedatectl and the Kestra docker container. I'll report as I have changed and tested with that.

[sebastianknopf]

After setting the timezone on the hosting machine back to UTC and restarting the kestra docker container, still facing the same issue ...

But until now I found that after chaning the flow definition and then refreshing the Admin > Triggers page, the 'next execution date' is 'running away', when having the 'timezone' property in the flow definition set explicitly). If I remove the 'timezone' property, everything seems to work properly but no executions are listed anyway.

For further debugging, I have reset the flow definition to your inital solution approach (without setting timezone property explicitly). I took a look into the database behind: Directly after updating, I can see the triggers 'next execution date' column is set to the correct next execution date:

The date is updated after each time the task should have been running. But still no listed executions ...

For further testing, I checked that the MySQL server, Kestra's docker container and and the hosting machine are running in the same timezone. Therefore, I restarted everything, disabled- and re-enabled the trigger in the UI and now it seems to work!

I'd run several tests until tomorrow and then inform you about the results. Idea?

[anna-geller]

Love how thorough you approach this! I believe this part is what made the difference:

I restarted everything, disabled- and re-enabled the trigger in the UI and now it seems to work!

the typical things in the UI — caching, after restarting/reenabling everything is often back to normal so not unusual

[sebastianknopf]

Okay, this seems no bug, but a configuration issue on my hosting system. After resetting the timezone information yesterday, everything works. The hosting machine and all related servers (Kestra, MySQL) should run in UTC.

I close this for now, thank you so much for your support!