А у тебя долгоиграющие датабазные транзакции там или что ты имел ввиду под «докоммитил»?

Соблюдается

нет, не очень, иногда по 15 сек могут длится, если запускается доп логика. но чаще всего это 2 - 3 сек где-то

я вот на диаграмке визуализировал и понял, что нет. как верно выше там кто-то заметил, что даже за 30мс может произойти много что

там на самом деле решение какое-то тупое, я смог решить задачу, зайдя с другой стороны (не посылая один ивент на кенселейшн)

но забыл :(

Чот понятно что ничего не понятно. Откуда там 15 секунд?

Вместо Send делал Publish?😂

я к тому, что сама сага длится в некоторых кейсах до 15 сек

Ну сага описывает заказ

Как я понимаю

У которго может быть конечный набор состояний

Ну вот и дополняешь парочкой новых

Это ж конечный автомат по сути

да. и там раундтрип в 8 - 12 сервисов (в зависимости от типа заказа)

и вот представим, что чекаем флаг на старте транзакции. всё окей, идём дальше. процессим пеймент, получаем там токен нонс, проверяем опять флажок перед финальным списанием.

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

да

Ну дык ты проверь после списания

И если забанили, то стартуешь рефанд

Прост в другую ветку развиваешь это дело

да как-то хотелось бы без лишних рефандов. но в целом да, я такое решение тоже рассматривал, из самых некостыльных оно самое адекватное

Ну для начала надо узнать какой процент таких вот потеряшек относительно общего количества заказов