Привет. Хелпаните советом, как можно предотвратить вызов callback в winzou

state machine, если во время смены статуса вылетает exception? через callback шлется емаил, но статус entity не менятся

exception - исключительная ситуация, дальше которой программа не должна продолжать свою работу

Почему не должна? Можно, например, повторить попытку.

Ну повторить попытку можно в том случае, если программа не отработала полностью, самому ретраю по сути пох какой там еxception, он долбит её пока она не завершится удачно

Думаю правильно будет сказать что есть 2 виза исключений: те которые мы ожидаем и потом программа отрабатывает с их учётом и те которые мы не ожидаем (или не хотим ожидать) после которых программа не имеет что выполнять

ты cчитаешь правильно ожидать исключение? )) тогда это и не еxception вовсе

когда вы заходите на страницу к которой у вас нет доступа Symfony кинет вам AcceddDeniedException, который в далтнейшем будет обрабатываться хэгдлером, который либо сделает редирект либо выдаст вам страницу на которой сказано что вам туда нельзя. Вам же приложение не выкенет стэктрейс со словами "А всё, эксэпшон, я дальше работать не буду". Мало того, есть NotFoundHttpException, как и другие http исключения, который будет превращён в ответ клиенту. Всэ эти исключения ожидаемы и для них есть хэндлеры, остальные не исеют хэндлеров, потому их выводят как Unhandled exception

когда страница кидает exception, на этом её дальнейшее выполнение прерывается, нет там никаких хендлеров, и даже если следовать вашему примеру Symfony Security и её AcceddDeniedException, метод контроллера не выполняется, контроллер не ходит в бд, не рендерит шаблон или json, Exception! Все, приплыли )), а тот стектрейс который мы видим в dev - это все что было до Exception

то что метод контроллера не выполняет не означате что дальнейшее выполнение прерывается, выполнение идёт по другой ветке логикик и далеко не всегда прерывает выполнения кода. Если вы ловите исключение в сервисе через try catch у вас не отваливает процесс, вы просто выполняет другую ветку логики если она у вас есть. нет там никаких хендлеров - если говорить про access denied исключение - смотриет security.yaml, настройка security.filewalls.*.access_denied_handler, если говорить о исключениях http семейства - смотрите на \Symfony\Component\HttpKernel\Exception\HttpExceptionInterface - их общий интерфейс ------ \Symfony\Component\HttpKernel\Controller - контроллер которые отображает эти ошибки (это к слову о том что метод контроллера не выполняется - выполняется, но уже другой ) ---- \Symfony\Component\HttpKernel\EventListener\ErrorListener::onKernelException - метод который отрабатывает через события ядра когда исключения такого типа кидаются

Если вы ловите try catch и выполняете другие ветки логики своей программы, то это неверный подход, т.к. повторюсь - это вовсе не исключение, верните вы bool в своем сервисе, ифом сверить - и результат будет тот же, также у вас ошибочное понятие с термином хендлер, либо слишком широкое, получается к любому классу можно сказать это хендлер ))

Если у вас слейв база данных отвалилась вы будете возвращать булеан и закачивать реквест или просто переключитесь на другой слейв? У меня достаточно четкое понятие хэндлеров и оно точно не ограничено названием метода handle в классе.

речь не идёт о том, чтоб не юзать исключения вовсе. речь о том, что исключение - это исключение в прямом смысле этого слова. то есть это исключительная ситуация, когда что делать дальше - ну вот абсолютно непонятно. в том же примере базой которая отвалилась: если база одна и она отвалилась - а что делать дальше? есть идеи? нету. нуок, бросаем исключение. если коннектов много, то каждый отдельный коннекшн должен бросать исключение, если к нему есть запрос, а база не альо. потому что ну а что еще делать? и это исключение ловится, обрабатывается и берётся следующий коннект. когда все перебрали и доступных не осталось - штош, на этом уровне абстракции код не знает что дальше делать и кидает исключение.

Вот, весьма верно подмечено. По сути если у вас есть возможность выполнить альтернативную ветку подведения то вы этим и займетесь, ведь есть исключения на уровне всего приложения, после которых у нас нет опции кроме как закончить работу, а есть исключения локального уровня (модуль, апи, бд и тд) которые могут иметь фолбэки или альтернативы. Я согласен с вашим ответом

Но и там тоже есть штатные ситуации, а есть исключительные. И путать одни с другими и оба кейса покрывать исключениями - неправильно

Сразу выкинул исключение, это ситуация исключительная и требует анализа, какого он упал? Память протекла? Пользователи положили запросами? Ок, потеряем мы n-пользователей, а что если мы всех их направим на другой?

Когда у вас слейв отваливается вы переключаете свое приложение на другого слейва или на мастер попутно отправив срочное сообщение команде

и в итоге собственноручно мы кладём весь сервис )) и вместо n-пользователей мы теряем всех ))

По причине чего?

по той же причине, по которой упал предыдущий, а причина нам не известна ))

Насколько плохо надо написать приложение на симфонии в компоновке с мастер-слейв группой чтобы у вас поочередно падали все инстанции БД. Если это дос то есть rate-limit, есть fail2ban есть куча всего. Если это тяжёлые запросы то это вопрос оптимизации. Все это решаемые вопросы, но честно, за всё время своей работы ни разу не видел чтобы БД так легко падала, тем более в компоновках мастер слейв

ну так это же не я накинул кейс, что слейв упал )) я лишь ответил на вопрос, что бы я сделал, если ... почем? потому что по этой же причине с вероятностью 99,9% упадут и другие

Я накинул этот кейс, потому что знаю что такие ОРМ как доктрина просто перейдут на другой слейв при такой ситуации. Что касается 99 процентов, единственное что может к такому привести это плохой код