Description
Description
I'm currently assessing the possibility for one of my clients to switch their scheduled task to the new Scheduler component once 6.3 is released.
Everything is going great so far but I found one thing limiting them: the fact that it is not possible to access the run datetime. And using the current datetime does not really seems appropriate to me as it could be not in sync if the Scheduler is catching up on some missed schedules.
This looks to me like a quite common use case with scheduled tasks (when one wants to run some kind of report generation for example) where you need the current month or week to know which timespan to use. And so supporting it looks appealing.
Any thoughts? Does supporting this use case would make sense?
/cc @fabpot @kbond (as it seems to me you have been the most active on this component so far :) )
I did some quick fiddling and it seems to be possible to yield the $time from the MessageGenerator, add it time to the ScheduledStamp and then the user is free to do what they want with a Middleware or a listener.
I have also tried to think about it could be done with events (#49803 ) but introducing a dependency to the Event Dispatcher only for this seems a bit overkill.
So far, I have not been able to find another more satisfactory way of supporting this use case.
Maybe someone has a better idea?
Example
Here is the listener that I wrote in the app to support this use case, as you can see it becomes relatively easy to get the date and transmit it (or do some logging or whatever you want):
#[AsEventListener(WorkerMessageReceivedEvent::class)]
class ScheduledStampListener
{
public function __invoke(WorkerMessageReceivedEvent $event): void
{
if(!$event->getEnvelope()->last(ScheduledStamp::class)) {
return;
}
if (!$event->getEnvelope()->getMessage() instanceof ManagementInformationReportCommand) {
return;
}
$event->addStamps(new HandlerArgumentsStamp([$event->getEnvelope()->last(ScheduledStamp::class)->at]));
}
}