@@ -105,7 +105,7 @@ The :class:`Symfony\\Component\\Scheduler\\Attribute\\AsSchedule` attribute,
105
105
which by default references the schedule named ``default ``, allows you to register
106
106
on a particular schedule::
107
107
108
- // src/Scheduler/MyScheduleProvider .php
108
+ // src/Scheduler/SaleTaskProvider .php
109
109
namespace App\Scheduler;
110
110
111
111
#[AsSchedule]
@@ -282,7 +282,7 @@ Then, define your recurring message::
282
282
283
283
Finally, the recurring messages has to be attached to a schedule::
284
284
285
- // src/Scheduler/MyScheduleProvider .php
285
+ // src/Scheduler/SaleTaskProvider .php
286
286
namespace App\Scheduler;
287
287
288
288
#[AsSchedule('uptoyou')]
@@ -362,15 +362,25 @@ recurring messages. You can narrow down the list to a specific schedule:
362
362
Efficient management with Symfony Scheduler
363
363
-------------------------------------------
364
364
365
- If a worker becomes idle, the recurring messages won't be generated (because they
366
- are created on-the-fly by the scheduler transport).
365
+ When a worker is restarted or undergoes shutdown for a period, the Scheduler
366
+ transport won't be able to generate the messages (because they are created
367
+ on-the-fly by the scheduler transport). This implies that any messages
368
+ scheduled to be sent during the worker's inactive period are not sent, and the
369
+ Scheduler will lose track of the last processed message. Upon restart, it will
370
+ recalculate the messages to be generated from that point onward.
371
+
372
+ To illustrate, consider a recurring message set to be sent every 3 days. If a
373
+ worker is restarted on day 2, the message will be sent 3 days from the restart,
374
+ on day 5.
375
+
376
+ While this behavior may not necessarily pose a problem, there is a possibility
377
+ that it may not align with what you are seeking.
367
378
368
379
That's why the scheduler allows to remember the last execution date of a message
369
380
via the ``stateful `` option (and the :doc: `Cache component </components/cache >`).
370
- This way, when it wakes up again, it looks at all the dates and can catch up on
371
- what it missed::
381
+ 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.::
372
382
373
- // src/Scheduler/MyScheduleProvider .php
383
+ // src/Scheduler/SaleTaskProvider .php
374
384
namespace App\Scheduler;
375
385
376
386
#[AsSchedule('uptoyou')]
@@ -392,7 +402,7 @@ To scale your schedules more effectively, you can use multiple workers. In such
392
402
cases, a good practice is to add a :doc: `lock </components/lock >` to prevent the
393
403
same task more than once::
394
404
395
- // src/Scheduler/MyScheduleProvider .php
405
+ // src/Scheduler/SaleTaskProvider .php
396
406
namespace App\Scheduler;
397
407
398
408
#[AsSchedule('uptoyou')]
@@ -421,7 +431,7 @@ your message in a :class:`Symfony\\Component\\Messenger\\Message\\RedispatchMess
421
431
This allows you to specify a transport on which your message will be redispatched
422
432
before being further redispatched to its corresponding handler::
423
433
424
- // src/Scheduler/MyScheduleProvider .php
434
+ // src/Scheduler/SaleTaskProvider .php
425
435
namespace App\Scheduler;
426
436
427
437
#[AsSchedule('uptoyou')]
0 commit comments