Att fånga appar som kraschar direkt efter publicering

Den 25 september godkändes tre publiceringar som lyckade trots att appens API kraschade några sekunder in i varje start. Eftersom de ”lyckades” kördes ingen återställning; en bakgrundskontroll underkände dem några minuter senare, och hela webbplatsen gick över till en 404. Hälsokontrollen räknade krascher i hostingplattformens händelselista — som bara rymmer de senaste fem händelserna per maskin, så en kraschloop håller listan full och antalet växer aldrig. Den jämför nu tidpunkten för den senaste kraschen i stället, och en publicering som kraschar i loop misslyckas och återställer den föregående versionen.

Vad en publicering väntar på

När du publicerar en app med backend på Mythex rullas den nya versionen ut på maskiner hos vår hostingplattform, och en hälsokontroll avgör om publiceringen gick live eller misslyckades. Om den misslyckades återställs den föregående versionen.

Det svåra är att ”startad” inte är detsamma som ”svarar”. Plattformen rapporterar en maskin som startad så snart den är uppe. En app som kraschar en sekund in i starten startas om direkt, och ett ögonblick senare visas den som startad igen. Så hälsokontrollen hade vuxit i några lager över tid:

1. Titta två gånger. Efter att en maskin visas som startad, vänta en kort stund och titta igen. En krasch vid start underkänns ofta vid den andra tittningen.
2. Håll utkik efter kraschloopar. Om plattformen rapporterar att en maskin kraschade upprepade gånger och att den gav upp att starta om den, misslyckas det.
3. Räkna krascher sedan publiceringen började. Två ”startad”-tittningar kan spänna över en omstart. Så om någon krasch skett sedan publiceringen började tittar vi en tredje gång; om det finns fler krascher än vid förra tittningen är appen inte stabil.

Det är den tredje kontrollen som fallerade här.

Varför antalet stod still

Kraschinformationen kommer från varje maskins händelselista: starter, avslut, omstarter. Plattformen behåller bara de senaste fem händelserna per maskin.

Tänk dig en app som kraschar 2,5 sekunder in i varje start, som en av dem gjorde. Varje cykel lägger till en krasch och en start. Efter ett par cykler är listan full. Därefter trycker varje ny händelse ut en gammal. Listan glider framåt, men den håller alltid ungefär samma blandning: ett par krascher, ett par starter.

Så ”hur många krascher sedan publiceringen började” gav samma svar vid varje tittning. Den andra tittningen såg kanske två krascher. Den tredje såg också två — andra krascher, men samma antal. Kontrollen drog slutsatsen att kraschandet hade upphört och godkände publiceringen.

Det hände tre gånger den 25 september, i två appar. Varje gång:

• markerades publiceringen som live,
• ingen återställning kördes, eftersom inget hade misslyckats,
• vår avstämningsprocess, ett bakgrundsjobb som kontrollerar deployeringar i efterhand, underkände deployeringen några minuter senare,
• och hela webbplatsen returnerade 404.

En publicering som misslyckas i tid går att återställa: återställningen lägger tillbaka den föregående versionen. En publicering som misslyckas några minuter för sent, efter att ha deklarerats lyckad, har redan hoppat över sin återställning.

Hur vi hittade det

Vi reproducerade det lokalt: tog ett fungerande API, lät det gå i vila och publicerade sedan om det med en ändring som kraschade vid start. Hälsokontrollen markerade det som live.

Det stämde med produktionen: i var och en av de tre publiceringarna dog appen några sekunder in i varje start, men antalet krascher som kontrollen jämförde ökade aldrig mellan tittningarna.

Lösningen: jämför den senaste kraschen, inte antalet

I stället för att räkna krascher tittar kontrollen nu på tidpunkten för den senaste kraschen sedan publiceringen började.

Om den andra tittningen visar någon krasch sedan publiceringen startade väntar kontrollen och tittar en tredje gång. Om den senaste krashen vid den tredje tittningen är senare än den senaste vid den andra, har maskinen kraschat igen emellan. Den är inte stabil, och publiceringen misslyckas med ett meddelande om att maskinen kraschat upprepade gånger sedan publiceringen och fortfarande startar om.

Detta fungerar oavsett hur kort händelselistan är. Ett glidande fönster med fem händelser kan dölja hur många krascher det var, men det kan inte dölja att en ny just inträffat — den senaste händelsen är alltid den som finns kvar.

Med denna ändring beter sig den lokala reproduktionen rätt: publiceringen misslyckas, och den föregående avbildningen återställs. Det finns också ett test som simulerar plattformens beteende — varje tittning lägger till en krasch och en start och trimmar listan till fem — och kontrollerar att utfallet blir ett misslyckande, inte en godkänd.

Det vi lärde oss

• Känn till formen på datan du räknar. En räkning över en kapad lista betyder inte längre något när listan är full. Begränsningen var inte dold; vi hade bara inte utformat kontrollen med den i åtanke.
• Föredra ”hände något nytt?” framför ”hur många hände?” Den senaste tidsstämpeln överlever att listan kapas. En summa gör det inte.
• Ett sent misslyckande är värre än ett tidigt. Samma trasiga bygge är ofarligt om publiceringen misslyckas och återställs, och slår ut en webbplats om den först deklareras lyckad.
• Reproducera under verkliga förhållanden. Buggen krävde en maskin som redan kraschat tillräckligt många gånger för att fylla sin händelselista. En enstaka snabb krasch i ett test hade inte visat den.

Denna rättning kompletteras av en annan från samma dag, som såg till att återställningen lägger tillbaka den gamla versionen i stället för att ta bort den: en misslyckad ompublicering raderar aldrig en fungerande backend. Om din egen app inte går att publicera för att den kraschar vid start är felsökningsdokumentationen för publicering och vår guide om felsökning av en AI-byggd app bra ställen att börja på.