Skip to content

Commit 428d866

Browse files
committed
[SCHEDULER] clarify idle state and stateful option
1 parent 8ac82c9 commit 428d866

File tree

1 file changed

+9
-4
lines changed

1 file changed

+9
-4
lines changed

scheduler.rst

Lines changed: 9 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -336,13 +336,18 @@ recurring messages. You can narrow down the list to a specific schedule:
336336
Efficient management with Symfony Scheduler
337337
-------------------------------------------
338338

339-
If a worker becomes idle, the recurring messages won't be generated (because they
340-
are created on-the-fly by the scheduler transport).
339+
When a worker is restarted or undergoes shutdown for a period, the Scheduler transport won't be able to generate the messages (because they are created on-the-fly by the scheduler transport).
340+
This implies that any messages scheduled to be sent during the worker's inactive period are not sent, and the Scheduler will lose track of the last processed message.
341+
Upon restart, it will recalculate the messages to be generated from that point onward.
342+
343+
To illustrate, consider a recurring message set to be sent every 3 days.
344+
If a worker is restarted on day 2, the message will be sent 3 days from the restart, on day 5.
345+
346+
While this behavior may not necessarily pose a problem, there is a possibility that it may not align with what you are seeking.
341347

342348
That's why the scheduler allows to remember the last execution date of a message
343349
via the ``stateful`` option (and the :doc:`Cache component </components/cache>`).
344-
This way, when it wakes up again, it looks at all the dates and can catch up on
345-
what it missed::
350+
This allows the system to retain the state of the schedule, ensuring that when a worker is restarted, it resumes from the point it left off.::
346351

347352
// src/Scheduler/MyScheduleProvider.php
348353
namespace App\Scheduler;

0 commit comments

Comments
 (0)