IOSOR

IOSOR Знания

Дублиращият се уебхук не трябва да създава втори дебит

Път на провала: повторните опити и възпроизвеждания остават идемпотентни за предплатените средства и входящата кутия — едно ID на събитие, един дебитен ред, един ред във входящата кутия.

Доставката поне веднъж ще направи повторен опит. Един дублиращ се уебхук, който изпраща втори дебит или втори ред във входящата кутия, е инцидент с пари и операции, а не «нещо безобидно». Тази страница показва пътя на провала: повторните опити и възпроизвеждания остават идемпотентни за предплатените пари и входящата кутия — това не е есе за идемпотентността на API заявките и не е ръководство за повторни опити при входящи SMS съобщения.

Свързани: Порта за подпис и прозорец за повторение, Уебхук договор преди първото изпращане, Дебитни редове vs статус на доставка в същия ledger.

Идемпотентността е път на провала, а не лозунг

Успешен път: едно подписано събитие, едно приемане, един дебит. Пътят на провала гори доверие — таймаут, 5xx грешка, възпроизвеждане от доставчика, повторно подаване от оператора. Съхранявайте ключа за идемпотентност от Уебхук договор преди първото изпращане преди страничните ефекти: ledger, входяща кутия, CRM.

Какво се брои за дубликат

Сигнал Третирай като дубликат когато Безопасен изход
ID на събитие Същото ID вече е прието в прозореца Потвърждение; без втори дебит
ID на съобщението Същото съобщение вече е свързано с ledger Използвай реда повторно; без ново таксуване
Ключ за входяща кутия Същото MO/MT вече е заведено Без втори ред във входящата кутия
Извън прозореца за повторение Стар опит след отхвърляне от порта Отхвърляне; без запис на пари/статус

Парите не трябва да се движат два пъти

Втори дебит за същото ID на събитие е грешка, дори ако продуктът «все още показва доставено». Финансите филтрират по събитие или ID на съобщение и виждат един предплатен ред за този UTC прозорец. Частичните странични ефекти след потвърждение — най-напред CRM, по-късно ledger — създават двойна истина. Ако обработката се провали след запазването, стартирайте работния процес отново със същия ключ; не приемайте HTTP тялото повторно като ново таксуване.

Входящата кутия също не трябва да се дублира

Идемпотентността не е само за пари. Възпроизведено входящо или доставено събитие, което отваря втора нишка във входящата кутия, учи поддръжката да гони духове и може да активира цикли за автоматичен отговор. Съхранявайте ключа за входящата кутия със същото ID на събитие, използвано за дебита. Продуктът и финансите споделят правила за отхвърляне и дублиране, за да поддържат входящата кутия чиста.

Чеклист за купувача за уебхуци, безопасни срещу дубликати

Тествайте възпроизвеждането преди пускане в производство. Изпратете същия уебхук два пъти последователно: първият генерира един дебит, вторият връща потвърждение без ново таксуване или ред. Проверете дали ledger на бекенда показва само един транзакционен ред за това време. Уверете се, че дневникът на грешките отделя истинските отхвърляния от повтарящите се опити.

Започнете с IOSOR

Принудете едно подписано повторение в прозореца на коридор, който вече е дебитирал. Експортирайте event id до id в книгата и докажете един ред дебит плюс един ред входяща. Ако се появи втори дебит, спрете този потребител и върнете излишния ред — не го нетирайте със следващ трафик. Тази врата е пари за повторение, не проверка E.164 и не текст за доставка.

Свързани: Уебхук договор преди първото изпращане Порта за подпис и прозорец за повторение Дебитни редове vs статус на доставка в същия ledger.

Обобщение IOSOR

Повторението не е ново изпращане. Едно event id пише един дебит.

Полезно ли беше ръководството?

Свързани ръководства