Ку всем. Есть вопрос. Есть у меня кароче команд хенделер,

юзаю команд бас. И у меня есть кейс где могут быть эроры в команд хендлере, и они должны транслейтится и отдаватся на фронт. Как мне это правильнее сделать?

есть встроеный транслейтер в симфе, можно его использовать

Он не переводчик имел в виду

Я знаю. Дело не в этом.

Можно поллить с клиента, или вебсокеты слушать.

Можно попробовать перевести ошибки в объемный бизнес флоу с востановлением. Ибо если сразу известно об ошибке то это не ошибка а просто один из вариантов развития событий. Вот и обработайте его соответственно.

а если там действительно exception ? имхо комманд бас не предназначен для передачи пользователю фидбека какого-либо в принципе

Если действительно ошибка в коде или база отвалилась то поправьте ваш код или инфраструктуру и ретрай команды завершиться успехом.

не, это понятно. но вот юзер об этом уже не узнает насколько я понял автору нужно именно получить фидбек от команды и _показать_ его юзеру

А вы как показываете фидбек юзеру?

а у меня нет проблемы, я не использую команд бас, он мне не подходит

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

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

Я тоже не юзаю. Но я так понимаю, чтобы следовать принципам команд баса - нужен websocket сервер(ну или периодически опрашивать серв аяксом или что то подобное). Как по другому?

а, если рассуждать чисто теоретически ? как выше сказали команд бас не предполагает фейла в принципе, все проверки на вероятность успеха должны проходить ДО того как отдается команда что-либо выполнить

Зачем так категорично. Вот это надо обычно это просто получается когда говорят как сделать. Но прогер не выясняет чего надо достичь. В итоге потом в чате решает проблему в том как хак воткнуть вместо того чтобы сделать по нормальному. Возможно поменяв логику процесс или/и UI

Предполагает. Он точно также сообщением может сообщить о том что стало. Главное не рассматривать фэил как что то другое от не фейла. Это всё результат.

То есть показать юзеру, что товар забронирован, не в момент реальной бронировки, а после успешного запроса на бронировку?

я неправильно выразился, согласен. не предполагает возврат некоего результата в привычном понимании для показывания пользователю

В таком случае овербукинг или неприкосновенный запас. Или компенсация решает проблему

по сути да

Стрёмная тема. Юзер может за это время наделать делов. Потом откатывай кучу всего. Я предпочёл бы показать юзеру только усшешной обработки команды, через тот же вебсокет. И только потом пусть юзер действует дальше.

для этого вам понадобится держать канал вебсокета уникальный для юзера и юзать es

Расскажите амазону про их стремную логику)

А зачем ес?

а как сокет узнает о результате работы команды где-то там в недрах системы ?

В таком же случае клиент должен знать, как изменится стейт после обработки команды. А это может быть сложной задачей. Придётся дублировать логику.

На клиенте генерим uuid для команды. Отправляем на сервер. Потом ждём ответа по нашему uuid. Точнее не ответа а сообщения по uuid

Зачем? Команда не говорит менять стейт команда говорит что надо сделать. Клиент априори знает что он хочет получить.

мне кажется это плохая идея писать в сокет прямо из команды

Я так и не предлагал. Мы шлем наш uuid через http запрос. Потом только слушаем сокет

Так в результате команды должен измениться стейт клиента. Может даже косвенно.

но сокет это отдельный сервис, он будет подписан на ивенты публикации данных в нужный сокет

Например? Зачем вам надо знать что там случилось и не достаточно что это просто случилось?

Баланс списан. Я больше не могу купить что то. Не хватает денек

например, деньги ушли реально или только запрос на перевод ушел

Ну скорее клиенту нужна связь не на конкретнуя команду, а на весь нужный ему стейт, чтобы он обновлялся.

Ага раскажите это банкам. Они вообще говорят ваш запрос будет исполнен если достаточно денег. И в ui просто меняется с надеждой на лучше. И не надо ничего ждать. Мы знаем что мы хотели и чего должны получить.

Ок. Не думал об этом. Спс. Вы реально на практике юзаете такой подход?

Но мы же в своих теориях лучше собаки. Зачем равняться на плохой сервис :)

Опять же если как у амазона кредитка только то мы тоже предполагаем что заплатится. А если не пройдет платеж то стопорим потом отправку и шлем письмо что денег не хватило.

Это как раз хороший сервис. Если вы заставите ждать 2 дня пользователя межбанковской транзакции. А она идёт 2 дня. Заблокировав ему все операции. Вот это плохой сервис.

межбанковская транзакция 2 дня - вот это плохой сервис, никогда не понимал причин

Поэтому что распределенность и независимость плюс eventual consistency. Хороший пример емеил. Если вы будете каждый раз по 10 минут ждать пока емеил дойдет это такое себе удовольствие. Там же все просто вам сразу говорят успех или спать. И если в редких случаях что то не так то потом сообщают другим письмом. Но в 99.99% этого не требуется. У пользователя ощущение что отправка работает мгновенно.

Мы же всё равно должны уведомить юзера как можно быстрее, что транзакция всё таки совершилась. Хоть это будет и через час.

Да не надо уведлмлять. Банки и не уведомляют. Они говорят о неуспешных. Также как и в примере и емейлами

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

оч просто. Кидаешь из команды эвенты. Типа "аттеншн, тут у нас ошибка". На эти эвенты подписывается штука, которая вещает их в потоке в паблик. будет ли это вебсокеты или server sent event или лонгполлинг не важно. Клиент на фронте тоже в свою очередь подписывается на интересные ему эвенты через этот вещатель. Получив событие выводишь уже инфу по нему и чоото делаешь.

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