Understrukna ord finns i lektionsordlistan. Tryck på ett ord för att se alla översättningar. Lägg till eller redigera ord i messages/glossary.json (alla språknycklar du lägger till visas i rutan).
Coding, debugging, and design
Debugging and troubleshooting steps
Jag har satt en breakpoint i funktionen för att se exakt vad som händer.
Låt oss kika i nätverksfliken i webbläsaren och se vilket svar vi får.
Jag har lagt in några console.log här och där för att spåra variabelvärdena.
Min första hypotes är att felet ligger i hur vi formaterar datumet.
Jag försöker isolera problemet genom att inaktivera andra moduler.
Låt mig stega igenom koden rad för rad med debuggern.
Jag ska kolla om felet kvarstår om vi kör med en helt ren databas.
Har vi kollat felloggarna på servern för att se om de säger något mer?
Låt oss kommentera ut den här delen av koden tillfälligt för att se om det löser det.
Jag undersöker just nu om det är ett problem med själva nätverkskopplingen.
Vi kan prova att starta om tjänsten för att se om minnet rensas.
Jag jämför just nu vår kod med förra veckans commit för att hitta ändringen.
Kan du skicka med den exakta payloaden som du skickar i Postman?
Vi borde kolla om cachen spelar oss ett spratt, testa i inkognitoläge.
Jag ska rulla tillbaka den senaste deployen för att se om det fixar systemet.
Jag försöker tvinga fram felet genom att skicka ogiltig data medvetet.
Låt oss granska databasfrågan direkt i SQL-klienten för att se resultatet.
Jag kollar stack-tracen för att se exakt var koden kraschade först.
Det kan vara värt att uppgradera paketet till den senaste versionen för att se om buggen är fixad.
Min nästa åtgärd blir att lägga till mer detaljerad felloggning i den här funktionen.
Jag ska verifiera om miljövariablerna är korrekt satta i produktionsmiljön.
Låt oss köra testerna i en isolerad miljö för att utesluta påverkan utifrån.
Jag rensar hela den lokala cachen och bygger om projektet från grunden.
Det kan vara en behörighetsfråga, har vi kollat rollerna för användaren?
Låt mig ssh:a in på servern och läsa loggfilerna i realtid.
Jag kollar just nu om databasen har nått sin gräns för antal maxanslutningar.
Vi kan testa att öka timeout-gränsen något och se om anropet går igenom.
Jag ska simulera en långsam nätverksuppkoppling för att testa laddo-tiderna.
Vi behöver kontrollera att DNS-inställningarna verkligen har slagit igenom.
Min teori är att variabeln hinner skrivas över innan löftet (promiset) returnerar.
Låt oss dubbelkolla så att det inte är brandväggen som blockerar porten.
Jag försöker förstå flödet genom att rita upp det på ett papper.
Ska vi ta bort testdatan och börja om på ny kula i databasen?
Jag använder profilering för att hitta vilken metod som suger mest prestanda.
Låt mig kolla i Event Viewer (händelseboken) på servern om operativsystemet klagar.
Vi borde analysera minnesdumpningen (heap dump) för att hitta läckan.
Jag ser till att tvinga systemet att logga på DEBUG-nivå en stund.
Kan vi skriva ett snabbt test-skript bara för att anropa just den funktionen?
Låt oss verifiera att vi skickar rätt content-type i headern.
Jag ska prova att skala ner bilderna för att se om minnesfelet försvinner.
Vi kan köra en git bisect för att exakt identifiera vilken commit som introducerade felet.
Jag dubbelkollar certifikaten för att säkerställa att de inte är ogiltiga.
Låt oss se om problemet reproduceras när vi byter till ett annat användarkonto.
Jag använder en proxy för att inspektera all HTTPS-trafik som skickas.
Vi kan slå på slow query log i databasen för att hitta flaskhalsen.
Jag ska granska källkoden i det externa biblioteket, de kanske har ändrat något.
Har du testat att rensa cookies och lokal lagring (local storage)?
Jag går igenom pull requesten från igår för att se om något uppenbart missats.
Låt oss testa att ändra sorteringen och se om felet flyttar på sig.
Vi är problemet på spåren, det är definitivt i parsern felet uppstår.
