Добрый вечер, настраиваю месенджер по этому руководству: https://symfony.com/doc/current/messenger.html Меня интересует возможность отправлять сообщения

"не ранее указанной даты". То есть при отправке сообщения в автобус иметь возможность задавать датувремя и чтобы сообщение обрабатывалось не раньше этой даты.

Сейчас планирую передавать дату время как поле сообщения, а в хендлере сообщения делать проверку: если дата ещё не наступила, то выбрасывать RecoverableMessageHandlingException

Но это очёнь стрёмный костыль. Есть решение лучше?

а не проще послать по крону? Так как если что-то случится в период между отправкой и началом обработке может сообщение потеряться, если этот период времени будет большим.

Дочитай доку до конца. Там пишут про делэи.

Не очень проще. Планируется рассылка большого количества сообщений разных типов. И некоторые из них вот имеют особенность, что нужно отправлять не раньше указанного срока. Выделять этот подсегмент отдельно в крон - как то размоет архитектуру. Хотелось бы сохранить в месенджере. Но не понял по поводу "случится между началом и и отравкой, то потеряется". Можете ли Вы пожалуйста, рассказать подробнее на примере?

Да, вот читаю про Stamps, спасибо. Это выглядит менее костыльно, но как то всё равно немного не то. там делей в секундах - насколько я понимаю - от времени попадания сообщения в автобус/ Для дебага как то несовсем удобно, когда отложить нужно на насколько недель например. Но не критично, буду пробовать

транспорт хоть уточни какой

doctrine

Ну mq это все же такая вещь предназначенная для независимой связки нескольких сервисов/программ. И на сколько я помню популярные брокеры сообщений не всегда хранят все очереди на диске. Да там можно вроде все это настроить, но все же. И они не предназначены для хранение данных. А в вашем случае вы там собираетесь хранить данные на протяжении недели. И на сколько я понимаю очередь будет пухнуть в течении недели. Хотя можно сгенерить сообщение именно тогда когда надо их обработать и отправить их в очередь. А случиться с очередью может что угодно. в полоть до того что допустим место закончится когда очередь будет пухнуть. А если отправлять сообщения в момент когда надо их обработать, то отправка и обработка очереди будет идти параллельно.

в данном кейсе сообщения сохранить отдельно в таблице, а в месаджере получать списки с необходимыми фильтрами и отправлять

Должно быть не важно какой транспорт. Сегодня это одно, а завтра уже может быть другой. И реализация не должна зависеть от транспорта.

а еще не важно какая база да ведь мы каждый день меняем базы на проекте

если это не опенсорс, то как скзал Сергей, зачем? Да и проекты чаще умирают, чем получают рзвитие до масштабофф "нужно поменять транспорт"