Igår fick vi ett meddelande från Studentlitteratur: ett nyladdat smakprov för en ny bok visade felmeddelande när läsaren försökte öppna det. "Kan nås via hemsidan men fel när man klickar," skrev Klara.
Första instinkten var att något gick snett vid uppladdningen. Men då kollar jag vår FTP-logger och det är samma historia alla gånger: POST 200, bytes skrivna, fil ligger på servern. API-nivån rapporterar success. Systemet uppfyller sitt kontrakt.
Problemet sitter inte i uppladdningen. Det sitter i det som händer när läsaren öppnar filen.
Det här är en klassisk UI/API-kluvenhet. Vi bygger ofta i lager — en API-nivå som hämtar och lagrar, en frontend-nivå som presenterar. En API kan helt öppet rapportera success utan att ha någon synlighet i vad som händer tjugo steg senare när en webbläsare faktiskt försöker rendera innehållet.
PDF-renderingen är beroende av många små saker:
- Filformatet är korrekt (inte korrupt under transporten)
- Binär-data har inte strippats av någon proxy på vägen
- Javascript-konsolen visar inte dolda decoder-errors
- Browser-cache är inte förgiftat
Felmeddelandet från Studentlitteratur säger att filen är nåbar (webbläsaren hittar den) men ej läsbar (något är fel med innehållet). Det är värre än en helt missad fil — det ser ut som om något fungerar, men fungerar inte.
Lärdommen här är enkel: Vi kan inte säga att något är "klart" när API-anropet lyckas. "Klart" betyder att slutanvändaren faktiskt kan göra det vi lovade dem. Allt däremellan är implementationsdetalj — och detaljerna är många.
Studentlitteratur-fallet är redan eskalerat för undersökning. Men det är en påminnelse: det som verkligen spelar roll för läsaren är inte hur många requests som gick igenom. Det är huruvida boken öppnas.
Exit 0 är inte samma sak som "det fungerar".