Я на собственном горьком опыте убедился, что тайм-аут не является сбоем. У нас была выплата, которая прошла на стороне провайдера. Их ответ так и не дошел до нас. Наша логика повторных попыток сделала именно то, что мы ей сказали, и клиент получил деньги дважды...
Я на собственном горьком опыте убедился, что тайм-аут не является сбоем.
У нас была выплата, которая прошла на стороне провайдера. Их ответ так и не дошел до нас. Наша логика повторных попыток сделала именно то, что мы ей сказали, и клиент получил деньги дважды.
Я помню, как некоторое время сидел с этим, потому что код был правильным. Каждая его строка делала то, что должна была. Неверное предположение было выше кода.
Мы сгенерировали ключ идемпотентности на границе запроса, HTTP-вызов получает UUID, провайдер выполняет дедупликацию по нему. Это работает до тех пор, пока ваша собственная служба не повторит попытку на более высоком уровне и не создаст новый ключ для той же передачи. Два ключа, одно намерение, и поставщик не может узнать, что они связаны.
Исправление заключалось в перемещении ключа на границу передачи. Один ключ на каждое деловое намерение, передаваемый при каждой повторной попытке ниже него.
На принятие второй части мне потребовалось больше времени: доверяйте своему состоянию больше, чем ответу провайдера. Тайм-аут — это не сбой, это неизвестность, и вы согласовываете его асинхронно вместо того, чтобы синхронно принимать решение по ответу, который так и не поступил.
Большинство ошибок оплаты, которые я видел с тех пор, не были удачными. Они находятся в промежутке между «это не удалось» и «я не знаю».