Quarkus quartz should not reschedule jobs on start

Describe the bug

Bug introduced by https://github.com/quarkusio/quarkus/issues/20538

Anytime quarkus starts it will reschedule jobs, not matter if the job config changed or not. It’s a tough decision, at best it should only detect changes and WARN, nothing else. This can have serious collateral damages depending on what your jobs are doing.

If you are cleaning up your data once a year, you don’t want that to be re initialized and triggered every time you restart the app or scale up your cluster.

Expected behavior

Do not reschedule jobs, WARN or maybe improve the dev tools but this is too dangerous.

Actual behavior

All jobs are rescheduled on start.

How to Reproduce?

Pick any quartz based clustered app. Create a job running every 5 sec for example.

Request the db for select * from qrtz_simple_triggers and select * from qrtz_triggers

Restart the app and check the table again. All triggers, executions are reset, ignoring past execution and, most important, the expected and persistent next_fire_time on qrtz_triggers.

Output of uname -a or ver

no impact

Output of java -version

no impact

GraalVM version (if different from Java)

No response

Quarkus version or git rev

since 2.3.1

Build tool (ie. output of mvnw --version or gradlew --version)

no impact

Additional information

No response

[ashwinair]

It would be helpful if you can share some follow-ups for me, Thanks.

You mean followup issues? If yes, let’s get this one in and we can look for others together I’ve couple of ideas.

Ya, sure it would be good for me too as I get to learn about quarkus more.

sorry for replying late, actually I was trying to fix my quarkus setup issues first before submitting my first pull request that’s why. can you check it out? #22717 Thanks 😃

[mkouba]

@machi1990 I think that solution 1 makes sense. What other state is lost BTW?

Whenever you change the @Scheduled.identity, remove the @scheduled annotation, quarkus is not in charge of cleaning up the qrtz_ tables related rows, this must be handled by the migration scripts (flyway), or manually.

@apat59 +1