сделал асинхронную отправку транспортных всд - результат  шокировал. на первый день увидел, что запросы с web-ответом статус 504 (gateway timeout) обрабатываются, на второй день увидел, что даже если тикет весит IN_PROCESS, в меркурии оформлен ВСД, кроме того alpm12 пришел на запрос ответа по тикету, удалив запрос ответа снова aplm12

заведите себе бложик.

(1) зачем? именно в одноимённой теме я понял, что работать с меркурием нужно асинхронно

У меня ассинхронные транспортные ВСД.
Про статус 504 не понял, у меня в случае ответа не 200 и не 500 посылает повторно, и дублей нет.
Если IN_PROCESS, то нужно ждать ответа. У меня разница между запросом на ВСД и запросом на тикет не меньше часа, и ни одного IN_PROCESS на 10000 ежедневных транспортных ВСД нет. На другие запросы есть (например регионализация), но тогда (в случае неответа после 100 попыток с паузой между ними в 1 секунду) я просто регионализацию повторяю заново.
aplm12 у меня нет совсем. Но я не пытаюсь получить ответ на тикет раньше чем через секунду после запроса, и если повторные запросы к Тикету из-за IN_PROCESS - то повторная попытка через паузу на секунду.

+ (3) И у меня работа идет в один поток. Возможно aplm12 из-за работы в несколько потоков.

(4) в один поток данные идут, тоже думал, что у меня в коде косяки, но когда аснихрон запустил, увидел, что мерк необрабатываемые запросы (со статусом 504) обрабатывает

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

(6) всё залогировано:
https://yadi.sk/i/SFGIXfYA3aLY7b
при отправке каждого запроса писал файлик, по именам файлов нашел, что было 2 запроса в разное время, содержимое файлов:
https://yadi.sk/i/Pmh24alg3aLY79

Включил контроль - за день две транспортных ВСД ушли, хотя не было положительного ответа с GUID тикета.