Kezdjük azzal, amit a többi olvasása közben a legkönnyebb elveszíteni: nem vettünk el pénzt. Egyetlen tárcát sem terheltünk meg kétszer, egyetlen kártyát sem terheltünk, és egyetlen előfizetési keretet sem költöttünk el olyan munkára, amely soha nem történt meg.
Ami elromlott, az egy szám volt a képernyőn. Néhány fióknál a saját fiókoldalad használati bontása többet mutatott — a legrosszabbnál, amelyet megmértünk, 2,4-szeresét annak a főkönyvnek, amelyet össze kellene foglalnia. A főkönyv végig helyes volt. Ugyanígy a havi plafonok is, amelyeket egészen máshonnan olvasunk. Megjelenítési hiba volt, javítva van, és itt az oka.
Egy kulcs, amely olyasmit keresett, amit senki nem írt ki
Az a munka, amely valamely műveleted nyomán indul — napi használati összesítő frissítése, ajánlási jóváírás könyvelése, értesítés szétküldése — nem a kérésed belsejében történik. A kérés kiír egy üzenetet, és egy háttérfogyasztó egy pillanattal később felveszi; épp ez akadályozza meg, hogy egy lassú mellékhatás lassúvá tegyen egy gyors oldalt.
Ennek az elrendezésnek a veszélye, hogy ugyanaz a munka kétszer fut le, mert egy közvetítő egy zökkenő után készséggel kézbesíti újra ugyanazt az üzenetet. A védelem egy beérkező postafiók: feldolgozás előtt a fogyasztó lefoglalja az üzenetet azzal, hogy kiír egy sort az üzenet kulcsával, és egy egyedi index lehetetlenné teszi a második foglalást.
A miénk egy páron foglalt — a bérlő, akihez az üzenet tartozott, plusz az üzenetkulcs —, és ezt a párt az üzenetboríték által hordozott bérlőazonosítóval szemben kereste, amely ki van töltve.
A foglalási sorok viszont egyáltalán nem hordoztak bérlőazonosítót. Mindegyik üres volt, és kezdettől fogva az volt. Az entitás saját dokumentációja szó szerint azt állította, hogy a keretrendszer beszúráskor rábélyegzi. Soha nem tette. A felfedezés napján az éles rendszeren mérve: a beérkező postafiók mind a 3344 sora üres, miközben a termelő oldalon 1451 sorból 1174 valódi bérlőt hordozott — pontosan ezért nem gyanakodott senki az olvasó oldalra.
A keresés tehát (bérlő, kulcs) párost kért, a tárolt sor (semmi, kulcs) volt, és soha nem egyezhettek.
Semmi nem bukott el, és épp ezért ment heteken át
Egy keresés, amely soha nem egyezhet, úgy hangzik, mint ami az első próbálkozásra hibát dob. Az ellenkezőjét tette.
A foglalás úgy döntött, hogy az üzenet friss. A beszúrás ezután nekiment az egyedi indexnek, és duplikátumként elutasításra került — helyesen, hiszen a sor már ott volt. Egy tartalék ág elkapta ezt az elutasítást, és jóindulattal olvasta: bizonyára egy másik kézbesítés foglalta le, itt nincs teendő. A boríték „még feldolgozandó" állapotban maradt, és mivel még feldolgozandó volt, a következő kézbesítés felvette, és újra elvégezte a munkát.
Minden fogyasztó nagyjából negyvenöt másodpercenként, vég nélkül újra feldolgozta a saját lemaradását. Huszonhatan csinálták. Egy éles sor 333 órával az érkezése után fejeződött be — és ennek az időnek a nagy részében újra meg újra befejeződött.
Mit rontott el valójában
A huszonhat fogyasztóból négy halmoz ahelyett, hogy felülírna. Ez a négy a számlázási vetület, amelyet a használati oldal olvas, és ott bukkant felszínre a dolog.
Volt kifejezett védelmük pontosan ez ellen, amelyet az augusztusi eset után írtak, amikor egyetlen esemény kilencszer került alkalmazásra egy mérőn. Ez a védelem a feldolgozás előtt jelöli sikeresnek a sort, hogy az ismételt kézbesítés megtalálja a jelölést és megálljon. A jelölés minden alkalommal helyesen íródott ki. A következő foglalás azután ugyanazzal a hibás kulccsal kereste, és nem találta. Ez a garancia a kiadása napjától fogva üres volt.
Amit ez nem érintett, érdemes pontosan felsorolni, mert a „számlázási vetület" riasztóan hangzik, a tények viszont nem azok:
- A főkönyv helyes volt. Minden MI-hívás pontosan egy számlázási rekordot ír ki a saját ár-pillanatképével, és ezen az útvonalon semmi nem írja őket.
- Egyetlen tárca sem mozdult. Az egyenlegek a főkönyvből jönnek, soha nem összesítőből.
- Egyetlen plafon sem mozdult. A költségvetési őr külön számlálót olvas, és az az egyetlen igazságforrás arról, mennyit költöttél ebben a hónapban. Senkit nem vágtunk el korábban egy felfújt szám miatt, és senki nem jutott át, akinek nem lett volna szabad.
Az érintett összesítőt egyedül a saját fiókoldalad használati előzménye olvassa — az összeged és annak bontása, mire ment el. Ennyi a teljes hatósugár, és annyiból állt, hogy többet mutatott.
A fél, amelyet senki nem nézett
Ugyanaz a hibás keresés egy második helyen is ült: azon az útvonalon, amely akkor fut, amikor egy üzenet elbukik. Ott soha nem találta meg a frissítendő sort, és közvetlenül alatta ült egy ág „a gyakorlatban elérhetetlen" megjegyzéssel — amely minden hibánál azt adta vissza, hogy „ez a hiba végleges".
Így az újrapróbálkozás-számláló soha nem haladt előre, és egyetlen mérgezett üzenet sem jutott el a holtlevél-sorba. A hibakezelés egy egész rétege ki volt kapcsolva, egy megjegyzés mögött, amely minden olvasójának azt mondta, hogy itt nincs mit ellenőrizni.
A javítás
Mindkét keresés immár az üzenetkulcsra kulcsol a fogyasztói csoporton belül, és az egyedi index amúgy is ezt kényszeríti ki. Az üzenetkulcsok az őket létrehozó dolog azonosítójából származnak, így felépítésükből adódóan nem ütközhetnek bérlők között.
A bélyegzést állító dokumentációt javítottuk, nem töröltük. Az a mondat volt maga a csapda, és a törlése semmit nem hagyott volna hátra arról, hogy végre valaki utánanézett.
Kilenc teszt rögzíti a viselkedést. Közülük hat elbukik a régi kódon, amit a régi kód visszatételével igazoltunk.
Utótakarítás
A felfújt sorok maguktól helyreállnak. Egy munkás óránként újraépíti a napi összesítőket a főkönyvből, kétnapos ablakon. Végig futott, és végig vesztett: óránként egyszer, egy negyvenöt másodpercenként újra alkalmazó fogyasztóval szemben, nem tisztességes verseny.
Mivel a fogyasztó már nem fut újra, a munkás nyer. Az a két nap, amely még az ablakon belül volt, a javítás élesedésekor azonnal újraépült a főkönyvből. Két korábbi nap már kiesett az ablakból, és ami rajtuk marad, az egy saját fiókunk plusz egy elhanyagolható eltérés máshol — így inkább meghagytuk őket, semmint hogy emiatt szélesítsünk egy ablakot élesben. Ezt jobbnak láttuk annál, mint azt sugallni, hogy a takarítás teljes volt.
Amit ebből elhoztunk
Egy deduplikációs kulcsnak azt kell tükröznie, amit az index valóban kikényszerít, nem azt, amiről a kód hiszi, hogy kiíródott. Ennek a kulcsnak a két fele különböző mezőkből táplálkozott, és egyiket sem mérte meg soha senki a másikkal szemben. Most már mindkettőt, és a tesztek, amelyek ezt bizonyítják, pirosra váltanak azon a verzión, amelyik hibás volt.