Middleware wrapper for job execution

[Insolita]

Может стоит добавить поддержку middleware в handleMessage чтобы можно было более гибко со стороны запуск контролировать, это позволило бы внедрять и дополнительные поведения в зависимости от класса job - в том числе для организации цепочек, и логику перезапуска внедрять, или например поведение командной шины запилить - навесив middleware с локатором, который передавал бы чистый dto job в хендлер - тогда и с конструкторами #59 проблем не должно быть
Middleware регистрируются в компоненте queue, а в handleMessage по извлечении job применяются пока не вернут статус handled. если не вернут, то вызывать $job->execute();
Да и на пуш тоже можно, тогда соответственно вся логика каких-то регистраций, менеджментов, создания-несоздания идентификаторов и прочего уже выносится на конкретные midlleware которые уже могут быть driver-depended и это будет гибче чем просто события для реализации нестандартной логики

[zhuravljov]

Именно middleware добавлять не хочу. Все же это расширение для Yii, и в библиотечном коде хотелось бы оставаться в рамках стандартных практик. А в Yii - это поведения. Тоже регистрируются в конфиге, последовательно выполняются, DI в конструкторе, и прочие плюшки.

Больше контроля со стороны поведений над отправкой заданий и их обработкой - хорошая идея. Последним коммитом добавил обработчику возможность заблокировать отправку задания в очередь, и блокировать запуск $job->execute() в момент обработки. А переопределять все возможные опции отправки можно было и раньше. Как пример closure\Behavior, который делает из анонимной функции job-объект. Также можно менять задержку выполнения, приоритет и время резерва.

Командную шину, на мой взгляд, лучше делать отдельным расширением поверх очередей. Там про вынос бизнес логики в отдельный слой, и асинхронная обработка команды - частный случай.