A hibátlan próbaadatból elkészülő feladatkártya még keveset mond arról, hogyan kezeli a rendszer a hétköznapi fennakadásokat. Egy hiányzó csatolmánnyal, két eltérő határidővel és egy kétszer beérkező kéréssel már megvizsgálhatod, hogy megáll-e, pontosítást kér-e, és elkerüli-e a duplázást.
Állítsd be a mivagyunk.hu-t kedvenc forrásként a Google-benElőször legyen egy működő, ártalmatlan alappróba
Képzelj el egy magyar kiscsapatot, ahol az MI a beérkező e-mailből belső feladatkártyát készít. Kiolvassa a kérést, megnézi a mellékelt munkalapot, határidőt rendel hozzá, majd értesíti a felelőst. A bemutatón minden adat a helyén van, a kártya gyorsan elkészül.
Az automatizálás hibakezelése akkor válik láthatóvá, amikor ebből a rendezett helyzetből kiveszel valamit. Ehhez a munkafolyamat tesztmásolatát használd, kitalált adatokkal, próbatáblázattal és tesztcímzettekkel. A próbaadat önmagában kevés, ha az értesítés továbbra is valódi ügyfélhez megy.
Először futtasd le a teljes, helyes mintát. Legyen egyetlen feladatkártya, a megfelelő határidővel és értesítéssel. Ezt az alapot másold le a három próbához, és minden esetben csak a vizsgált körülményt változtasd meg. Minden új tesztesethez használj friss azonosítót; csak a duplázási próbán belül ismételd ugyanazt.
A tágabb felkészüléshez az élesítés előtti tesztelésről szóló útmutatónk ad szempontokat. Itt három konkrét hibát viszünk végig.
Vedd ki a kötelező csatolmányt
A levél hivatkozzon a mellékelt munkalapra, de a fájlt hagyd le. Ebben a példában a feladat csak a munkalap alapján készíthető el, ezért annak hiánya megállási feltétel.
A megfelelő működés lehet egy hiánypótlást kérő üzenet és egy jól látható, hiányos állapot. A rendszer ne találja ki a munkalap tartalmát, és ne állítsa a feladatot végrehajtható állapotba. Ha külön nyilvántartja a beérkezett kérést, abból derüljön ki, hogy feldolgozásra vár.
Nézd meg a próbatáblázatot és az értesítéseket is. Előfordulhat, hogy az MI szövege jelzi a hiányt, miközben egy későbbi lépés mégis létrehozza a késznek látszó feladatot.
Az n8n dokumentációja például külön hibakezelő folyamatot és feltételhez kötött leállítást is bemutat. A hiányzó kötelező adat észlelését, a leállítást és a jelzést azonban bele kell építeni a folyamatba.
Adj meg két egymásnak ellentmondó határidőt
Állítsd vissza a csatolmányt. Az e-mailben most 2026. november 10. szerepeljen, a munkalapon november 12. Egyik se legyen módosításként megjelölve, és ne legyen előzetes szabály arról, melyik forrás az irányadó.
Ebben a próbában az elvárt eredmény a két dátum megjelölése és célzott visszakérdezés. A rendszer ne válasszon magától korábbi vagy későbbi határidőt, és a pontosításig ne indítsa el a határidőhöz kötött további műveleteket.
Ha a cégeteknél van jóváhagyott forrássorrend, a tesztet ahhoz igazítsd. Ilyenkor azt kell ellenőrizni, hogy a rendszer valóban követi-e a szabályt, és visszakereshető-e miből választott. Az elfogadható működést még a futtatás előtt írd le.
Küldd be ugyanazt a kérést kétszer
A harmadik próbához ismét a helyes alapadatot használd. Ugyanazt a tesztkérést, ugyanazzal a kérésazonosítóval juttasd be kétszer. Először egymás után próbáld, majd rövid időközzel, amikor az első feldolgozás még folyamatban lehet.
A végén egyetlen feladat és egyetlen szükséges értesítés maradjon. A második beérkezést a rendszer azonosítsa ismétlésként. A javított tartalmú új változat külön eset, azt nem szabad pusztán a hasonlóság miatt eldobni.
Az n8n ismételt kérésekről szóló útmutatója szerint az automatikus újrapróbálkozások duplázást okozhatnak. A védelemhez tartós kérésazonosító és a már feldolgozott műveletek ellenőrzése használható. Ezt a működést a munkafolyamat és a kapcsolt rendszerek szintjén is biztosítani kell; egy chatbotnak adott kérés önmagában nem garantálja.
A javítás után ugyanazokat a próbákat ismételd meg
Minden teszthez rögzítsd a bemenetet, az elvárt működést és a tényleges eredményt. Írd mellé a létrejött rekordok és értesítések számát, valamint azt, kinél jelent meg a fennakadás. A rendszer sikerjelzése mellett ezek mutatják meg, mi történt.
Ha valamelyik próba elbukik, javítsd a folyamatot, majd futtasd újra a helyes alapmintát és mindhárom hibás esetet. Így az is kiderülhet, ha a módosítás egy korábban működő ágat rontott el.
Három sikeres hibapróba még nem teljes körű minősítés. Arra viszont alkalmas, hogy a csapat konkrétan megmutassa, hogy kötelező adat nélkül hol áll meg a munka, ki pontosítja a bizonytalan határidőt, és mitől nem készül el ugyanaz a feladat kétszer.
