Kontakta supporten

Vi svarar via e-post, oftast inom två dagar.

Google reCAPTCHA kontrollerar det här inskicket mot missbruk; data skickas till Google. Skriptet laddas först när formuläret öppnas.

← Alla inlägg

Vad en radering av en räknare faktiskt berör

Att radera en räknare här tömmer 33 tabeller. I går tömde det 25.

De åtta som missades hade alla skapats dagen innan, mellan 11.10 på förmiddagen och 15.10 på eftermiddagen.

33 tabeller innehåller något om en räknare 8 av dem tömdes inte — alla skapade dagen innan de åtta innehöll sammanlagt 4 840 rader infogade i dag på sin alfabetiska plats, inte lagda sist 25 övergivna rader hittades i andra tabeller och togs bort

Så fungerar radering

En ägare kan radera sin räknare. Det kräver en POST, ägarens token och räknarens nummer inskrivet för hand, eftersom det inte går att ångra. Ingenting läggs undan: en skuggkopia vore motsatsen till det som begärdes, och exportlänkarna finns ovanför knappen för den som vill ha en kopia.

Sedan töms en lista med tabeller i en enda transaktion, huvudtabellen sist, och en gravsten läggs i arkivet så att numret aldrig kan delas ut till någon annan. Om någon del misslyckas rullas alltihop tillbaka. Inget raderat är bättre än halvt raderat.

Ovanför den listan, i filen, står den här kommentaren:

”Varje tabell som vet något om den här räknaren. Som en lista och inte utspritt i koden: det som saknas här blir kvar som en övergiven rad, och ingen märker det.”

Kommentaren beskrev luckan en dag innan den uppstod

I går dök sex nya tabeller upp för en ny funktion — tid på sidan, scrolldjup, utgångssidor — tillsammans med två andra. Mellan 11.10 och 15.10.

Raderingslistan redigerades samma dag, för att lägga till en annan ny tabell. De åtta kom efter det, och listan ändrades inte igen. Under en eftermiddag lämnade alltså en radering av en räknare kvar 4 840 rader beteendedata, fördelade på åtta tabeller. Luckan hittades nästa dag och stängdes; det den blottlade var att listan behövde något annat än minnet för att hållas komplett.

Det här är ingen berättelse om slarv. Någon skrev listan, förstod exakt varför den var en lista, skrev ner vad som händer när den halkar efter och uppdaterade den samma dag för en tabell. Och ändå halkade den efter, eftersom att hålla två saker i takt genom att komma ihåg det är något människor gör pålitligt ända fram till den eftermiddag då de inte gör det.

Lösningen, och den andra lösningen

De åtta namnen finns i listan nu. De infogades på sina alfabetiska platser i stället för att läggas sist, eftersom en sorterad lista gör en lucka synlig och en lista som bara fylls på i slutet inte gör det.

Det är den lilla lösningen. Den som spelar roll är ett skript som frågar databasen vilka tabeller som innehåller ett räknarnummer, läser listan ur källfilen i stället för att upprepa den, och jämför. Den som lägger till en tabell kör det en gång. Det kan inte glömmas bort på samma sätt som en lista, eftersom det inte lagrar något — det härleder svaret ur schemat varje gång.

Det hittade något annat vid första körningen: 25 rader i ytterligare åtta tabeller vars räknarnummer varken finns i den aktiva tabellen eller i arkivet. Inte raderade räknare — de lämnar en gravsten. Nummer som inte hör till någonting alls, de flesta uppenbara testnummer från tiden innan arkivkontrollen fanns. De skrevs till en fil utanför webbroten och togs sedan bort.

Den allmänna lärdomen

Varje lista som måste hållas i takt med något annat kommer till slut att komma ur takt, och luckan kommer att vara osynlig, eftersom en lista som saknar en post ser exakt likadan ut som en lista som är komplett.

Försvaret är inte disciplin. Det är att härleda den ena sidan ur den andra och kontrollera att de stämmer överens — och att köra den kontrollen i det ögonblick någon lägger till något, inte i det ögonblick någon börjar undra.

Kommentaren ovanför listan hade rätt om allt utom ett ord. Den sa att ingen märker det. Någon gjorde det, en dag senare, eftersom hen letade med ett skript i stället för med minnet.

Annons