Dupla beküldésből ne legyen dupla feladat

Egy ember és egy beküldés nem ugyanaz

Egy érdeklődő kétszer is megnyomhatja a küldés gombot, és egy szolgáltatás is megismételhet egy korábbi eseményt. Ettől még ugyanaz az ember jövő héten egy teljesen új munkát is kérhet. Ha minden ismétlődő e-mail-címet eldobunk, érvényes megkeresések veszhetnek el.

Első választásként a forrás által adott stabil beküldésazonosítót használnánk. Ha két külön űrlap azonos formátumú azonosítót készít, a kulcs a forrást is tartalmazza. Az e-mail-címre épített kapcsolattartó-összevonás külön üzleti döntés legyen.

A feldolgozási állapotot is őrizd meg

A saját tervezési mintánk három kérdést választ szét: láttuk-e az eseményt, tároltuk-e a kérést, és elkészült-e a következő művelet? A puszta »már láttuk« jelölés kevés, ha a folyamat a tárolás után, de az értesítés előtt állt le.

Javasolt állapotok: átvett, tárolt, értesítésre vár, kész, javítandó. Újrapróbáláskor a hiányzó művelettől folytasd. Éles, párhuzamos végrehajtásnál a kulcs lefoglalását az adattárolóban egyetlen atomi művelettel kell biztosítani; egy külön keresés, majd beszúrás közé másik futás férhet be.

Mit ad az n8n és a Make?

Az n8n Remove Duplicates node külön tud az aktuális bemeneten belül és korábbi futásokhoz képest ismétlést keresni. A tárolt előzmény mérete és hatóköre számít; a dokumentációban az alapértelmezett előzményméret 10 000 tétel. Ez nem korlátlan, üzleti eseménykönyvelés.

A Make Data Store tartós adatok tárolására szolgálhat scenariók között. A saját kulcsképzést, állapotváltást és a párhuzamos írás viselkedését ettől még meg kell tervezni és külön ellenőrizni. Egy demóban működő memóriabeli halmaz nem helyettesíti az éles állapotkezelést.

A négy legfontosabb próba

Ezek javasolt elfogadási helyzetek, nem a Cloud-szolgáltatásokon végrehajtott teszteredmények. Minden teszthez rögzítsd a bemenetet, a várt kimenetet és a tényleges kimenetet.

• Ugyanaz az eseményazonosító kétszer: egy tárolt kérés, legfeljebb egy üzleti művelet.
• Ugyanaz az e-mail, új eseményazonosító: új megkeresés maradjon meg.
• Leállás tárolás után: a folytatás ne hozzon létre második rekordot.
• Két párhuzamos azonos esemény: csak egy futás szerezze meg a feldolgozás jogát.

Ne töröld csendben a gyanús tételeket

Ha nincs stabil eseményazonosító, a hasonló tartalom csak gyanú. Ilyenkor egy kézi ellenőrzési sor gyakran jobb, mint egy agresszív automatikus szűrő. A naplóban a döntés okát és egy belső azonosítót őrizz meg; a teljes megkeresést ne másold indokolatlanul minden hibajelentésbe.