типо бла.бла.023 -заказ создан бла.бад.045 -крах

в логе это запись лога
как вариант побольше событий логировать что бы понять последовательность действий

крах из за попвтки нарушений ключа БД

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

Да и так ясно, наз-е ключа типо: ОТДЕЛ20211202173850

ПЕРЕВОД:ОТДЕЛ 2021 12МЕС 02 ДЕНЬ 17:38:50

Только чуть сложнее)

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

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

но будет проблема с дублями в БД

ОТДЕЛ20211202173850 создан

ОТДЕЛ20211202173850 через миллисекунды - попытка записи с таким же именем

Проект не я писал, и наз-е необходимо такое

формата

без милисек

Поэтому разница в названии (шаг 1 сек)

Вот и думай, что за хрень происходит втечение несклько миллисек, почему (либо UI, либо хз....)

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

и время с сервера берется или клиента

время серв есте-но)Ну уж обижаете)

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

Так надо добавлять больше логов, в том числе на клиенте