En app som inte fått en regel om krockar sparar oftast det som kommer in sist och säger ingenting till den som förlorade. Du kan beställa tre andra beteenden i klartext: en spärr, en varning eller en sammanslagning. Vilket du väljer beror på vad som är värst i just din app, ett nej till en användare eller en ändring som försvinner. Öppna sedan samma post i två fönster och se efter vad som faktiskt händer.
Appen har redan bestämt sig, fast du inte sa något
När du beskrev appen sa du vad en användare ska kunna göra: anmäla sig, ändra en uppgift, ladda upp en fil. Du sa ingenting om vad som ska hända när två gör det mot samma sak i samma stund, och det är inte konstigt, för det är inte en situation du ser när du provar själv. Byggverktyget fyllde i luckan åt dig med det enklaste som fungerar när det bara finns en användare: det som sparas sist gäller.
Det lömska är att båda användarna får samma bekräftelse. Den som ändrade adressen ser ”Sparat”. Den som ändrade telefonnumret ser ”Sparat”. Först nästa gång någon öppnar posten syns det att bara den ena ändringen finns kvar, och då är det omöjligt att veta vad den andra skrev. Det finns ingen felrapport att ta emot, för ingen såg något gå fel.
Tre krockar täcker det mesta du kommer att bygga: två som vill ha den sista platsen på något med ett tak, två som redigerar samma rad, och två som laddar upp en fil med samma namn. Standardutfallet är detsamma i alla tre: sist in vinner, tyst. Beställningen skiljer sig.
Tre beteenden du kan beställa i klartext
Du behöver inte veta hur verktyget löser det. Du behöver bara kunna säga vilket av tre utfall du vill ha, och veta vad vart och ett kostar.
Provet på att du valt rätt är att du kan svara på en fråga: vad är värst i just den här funktionen, att en användare får ett nej eller att en ändring försvinner? Kan du inte svara har du inte bestämt dig, och då bestämmer verktyget.
Krock 1: sista platsen på ett evenemang
Kursen bygger en anmälan med ett tak på 30 platser, och redan där står en mening som är lätt att läsa förbi: kontrollen av taket måste ske där data sparas, inte bara i det som visas. Här är skälet. Två personer öppnar sidan samtidigt. Båda ser ”1 plats kvar”. Båda fyller i formuläret och trycker på Anmäl. Om appen bara räknade platserna när sidan visades har den ingen aning om att räkningen är gammal när den andra anmälan kommer in. Resultatet är 31 anmälda till 30 platser, och ingen av dem har fått veta det.
Här är ett nej det utfall som håller. Två personer kan inte dela på en stol, och en varning har inget att visa: det finns ingen ändring att jämföra med, bara en plats som inte längre finns.
Aktiviteten har ett tak på [30] platser. Två personer kan skicka in anmälan i samma sekund. Då ska exakt en av dem få platsen och den andra ska få beskedet "Platsen hann ta slut" i stället för en bekräftelse. Antalet anmälda får inte överstiga taket, oavsett hur många som trycker samtidigt. Kontrollen av taket ska göras i samma stund som anmälan sparas, inte när sidan visas. Förklara i klartext, utan kodord, var den kontrollen sitter och varför två samtidiga anmälningar inte kan passera den båda två. Ändra ingenting annat.
Provet: sätt taket till 1 plats i en testkopia av appen, öppna anmälningssidan i två fönster så att båda visar ”1 plats kvar”, fyll i båda och tryck på Anmäl i det ena och direkt därefter i det andra. Rätt utfall är en bekräftelse och ett tydligt nej, och en enda rad i listan över anmälda. Ser du två bekräftelser eller två rader i listan har taket bara kontrollerats i det som visas, och beställningen ovan är inte uppfylld.
Det här provet har en gräns du ska känna till: du trycker i tur och ordning, inte i exakt samma ögonblick. Det räcker för att avslöja en app som inte kontrollerar alls vid sparandet. Det bevisar inte att kontrollen håller när två anmälningar verkligen kommer in inom samma bråkdel av en sekund. Därför ber beställningen verktyget förklara var kontrollen sitter, och därför ska du läsa svaret. Nämner svaret ett ”lås” (att appen håller platsen reserverad medan den första anmälan avslutas, så att den andra får vänta och sedan får nej) eller att kontrollen och sparandet sker i ett enda odelbart steg, är du på rätt spår. Säger svaret bara att sidan räknar om platserna oftare är du det inte.
Krock 2: två som redigerar samma rad
Två kollegor har samma kund öppen. Den ena rättar adressen, den andra lägger till ett telefonnummer. Båda trycker på Spara med några minuters mellanrum, och båda får ”Sparat”. Standardutfallet är att hela formuläret skrivs tillbaka, inte bara det fält som ändrades. Den som sparade sist skickade med den gamla adressen utan att veta om det, och adressrättningen är borta. Ingen av dem gjorde fel, och ingen kommer att kunna säga när det hände.
Här är en varning oftast rätt, och en sammanslagning ett bra tillägg. Ett nej vore ett dåligt val: det är inte upptaget, det är bara ändrat, och den andra personens arbete är lika giltigt.
Två användare kan ha samma [kund] öppen för redigering samtidigt. När den andra trycker på Spara och posten har ändrats av någon annan sedan hen öppnade den ska ingenting skrivas över tyst. Om de två ändrade olika fält ska båda ändringarna sparas. Om de ändrade samma fält ska den som sparar sist få se en varning med det värde som nu ligger sparat och sitt eget värde bredvid, och själv välja vilket som ska gälla. Bekräftelsen "Sparat" får bara visas när det som visas på skärmen är det som ligger sparat. Ändra ingenting annat.
Provet är tvåfönsterprovet nedan, och avläsningen är exakt. Rätt utfall när fönstren ändrade olika fält: båda värdena finns kvar när du laddar om sidan i båda fönstren. Rätt utfall när fönstren ändrade samma fält: det andra fönstret visar en varning med båda värdena i stället för ”Sparat”. Fel utfall: ”Sparat” i båda fönstren och ett värde som saknas efter omladdning. Det sista är tyst dataförlust, och det är exakt det du letar efter.
Krock 3: två som laddar upp samma fil
Två deltagare laddar upp sin bild, och båda heter bild.jpg. Två användare i samma förening laddar upp var sin version av protokoll.pdf. Standardutfallet är att den andra filen skriver över den första, för att appen använder filnamnet som adress och samma adress bara kan peka på en fil. Den första deltagaren ser fortfarande en bild i sin profil. Det är bara inte hens bild längre.
Här är utfallet enklare än i de andra två fallen: den ena filen ska inte ersätta den andra utan att någon bett om det. Vill du att en användare ska kunna byta ut sin egen fil är det en annan sak, och det ska då kräva att hen laddar upp till just den platsen, inte att filnamnet råkar vara samma.
Flera användare kan ladda upp filer med samma filnamn, ibland i samma sekund. En uppladdad fil får inte ersätta någon annan användares fil, oavsett filnamn. Ge varje uppladdad fil en egen adress som inte bygger på det namn användaren gav filen, men visa användarens eget filnamn i listan. Om samma användare laddar upp en ny fil till samma plats ska hen först få frågan "Ersätta den befintliga filen?" och ett nej ska behålla den gamla. Ändra ingenting annat.
Provet: gör två små textfiler på din dator som båda heter test.txt, med innehållet ”A” i den ena och ”B” i den andra. Logga in som två olika testanvändare i två fönster och ladda upp A från det ena och B från det andra. Öppna sedan båda filerna från appen. Rätt utfall är att den första användaren ser ”A” och den andra ”B”. Ser båda ”B” har den andra uppladdningen skrivit över den första. Ladda till sist upp en tredje fil med samma namn som samma användare och kontrollera att frågan om att ersätta dyker upp, och att ett nej faktiskt behåller den gamla.
Tvåfönsterprovet: samma post, två fönster, en avläsning
Provet kräver ingen kod och ingen andra person. Du spelar båda användarna själv, och nyckeln är att du inte laddar om något fönster förrän du har sparat i båda. Gör det i en testkopia eller med en tydligt märkt testpost, inte på en riktig kund.
Bekräftelsen säger att appen tog emot det du skickade. Den säger ingenting om vad som fanns där innan eller om någon annans ändring försvann på vägen. Beviset är omladdningen i steg 4: det som står där är det som ligger sparat. Skriv upp resultatet innan du beställer något, så kan du jämföra efter rättningen.
Skriv in provet som tre rader i din provlista: olika fält, samma fält, samma filnamn, med förväntat utfall för var och en. Det här är en funktion som slutar fungera vid ändringar ingen kopplade till den, till exempel när verktyget bygger om formuläret för att du bad om ett nytt fält.
Var provet slutar och kodläsning tar vid
Tvåfönsterprovet hittar den vanliga varianten av felet: en app som inte kontrollerar något alls vid sparandet. Det du inte kan bevisa själv, utan att läsa kod, är att kontrollen håller när två anmälningar eller två uppladdningar verkligen landar inom samma bråkdel av en sekund. Där tar en annan sorts arbete vid. Har du någon i närheten som läser kod, eller vill du själv förstå vad verktyget byggde, förklarar Monkeybases artikel om samtidighetsbuggar i AI-genererad kod mönstret modellen skriver, hur felet provas avsiktligt och vilka tre åtgärder som håller. Den här sidan slutar där den börjar.
Blanda inte heller ihop två användare som krockar med många användare som belastar. Om appen blir långsam eller stannar när hundra personer kommer samtidigt är det ett annat problem med andra beställningar, och det har artikeln om att skydda appen mot överbelastning. Två personer som vill ha samma stol är en krock även på en helt tom server.
Är du fortfarande i kursen och bygger anmälan hör beställningen om sista platsen hemma i delen om att spara data, där taket beställs första gången. Lägg till spärren där, inte som en separat funktion efteråt. Beställningarna och proven ovan kontrollerades 19 september 2026.
Klart när du vet vem som vinner, och den andra får veta det
Arbetet är klart när du för varje ställe i appen där två användare kan röra samma sak kan säga vilket av de tre beteendena som gäller, när tvåfönsterprovet ger det utfall du beställde, och när den som förlorar en krock ser ett besked i stället för ”Sparat”. Du behöver inte kunna förklara hur verktyget gjorde det. Du behöver kunna visa att det blev så.
Var i appen kan två personer röra samma sak? Ska den andra få ett nej, en varning eller båda ändringarna? Och när provade jag senast samma post i två fönster?