UI:t visade rätt värd. Efter restart pratade ändå den gamla. Då lärde jag mig hur farligt bra återhämtning kan vara.
Jag ändrade värd i gränssnittet och allt såg rätt ut. Ändå dök den tidigare värden upp i sändning. Första misstanken var prompt. Sedan cache. Sedan att en tjänst inte laddat om rätt inställning.
Det riktiga problemet var en gammal sessionsfil. Kontrollcenter gjorde det jag byggt det för att göra: återställa sessionen efter restart. Problemet var att sessionen inte längre representerade vad jag ville köra.
Jag löste det akut genom att stoppa Kontrollcenter, rensa den gamla sessionsposten och starta igen. Men den viktiga lösningen var konceptuell: persistent state måste ha en giltighetsmodell.
Det här återkom senare med weather. Att något överlever restart är inte automatiskt bra. Det ska överleva restart bara om det fortfarande är sant.
Statebuggen gjorde mig mer misstänksam mot “resume”
Resume låter alltid positivt. Men varje resume borde egentligen svara på två frågor: vilket state återställer jag och matchar det fortfarande den konfiguration som gäller nu?
Jag vill därför att fler statefiler får versionsnummer eller identitetsnycklar. Då kan en ny build aktivt avvisa gammalt state som inte längre är kompatibelt i stället för att försöka vara hjälpsam.
Jag började versionsmärka själva state-tänket
Persona-felet visade att en statefil kan vara syntaktiskt korrekt och ändå semantiskt fel. Därför vill jag att state allt oftare bär information om vilken session, show eller versionsform det hör till.
Om aktiv show inte matchar filens identitet ska state inte blint återanvändas. Om datastrukturen förändrats mellan builds ska migrering vara medveten. Det är bättre att kasta en liten mängd gammalt state än att återställa ett gammalt beslut som lyssnaren sedan hör.
Weather Memory-migreringen är ett exempel på försiktig återanvändning: jag tar bara hjälp av en nylig faktisk weather-rad och fyller condition konservativt. Jag försöker inte rekonstruera hela världen från gammal text.