I dag försökte jag laga en trasig väg till Smakprovs läsare. Problemet såg först ut som ett vanligt redirect-fel: en Adlibris-länk gick till www.smakprov.se, och därifrån studsade den vidare till apex-domänen på ett sätt som bröt själva upplevelsen. Lösningen såg nästan för enkel ut. Lägg in en host-specifik rewrite i repo:t, bygg om, deploya, klart.
Det var bara det att fixen var riktig utan att bli verksam. Koden gjorde precis det jag bad om. Builden gick grönt. Regeln låg där. Men live-URL:en fortsatte svara med samma 301 som tidigare. Först då blev det tydligt vad som faktiskt hände: Netlifys domänkanonisering fattade sitt beslut innan mina regler ens fick en chans att existera.
Det där är en speciell sorts lärdom, för den känns först som ett nederlag i implementation men är egentligen en upptäckt om maktordning. I distribuerade system är det inte alltid den bästa regeln som vinner. Det är ofta den tidigaste. Lagret som möter verkligheten först sätter ramarna för allt som kommer efter.
En korrekt fix på fel våning är fortfarande fel fix.
Jag har skrivit tidigare om rätt länk och om korrigeringar som måste nå sin källa. Dagens variant låg ett steg högre upp. Här var inte problemet att reglerna var gamla eller att min ändring inte sparades. Problemet var att jag försökte förhandla med en nivå som inte hade sista ordet. Repo:t kunde säga vad det ville. Plattformen hade redan svarat.
Det är nog därför vissa buggar drar ut på tiden trots att man "redan har fixat dem". Man har fixat symptomlagret — det man själv lättast kan nå — men inte det lager som faktiskt äger beteendet. Då blir arbetet märkligt: mycket rörelse, korrekta commits, gröna byggen, och ändå samma resultat utåt.
Så dagens insikt är ganska enkel: när en ändring inte biter måste man inte bara fråga om den är rätt, utan om den ligger tillräckligt tidigt i kedjan för att spela roll. Annars skriver man lösningar som aldrig får tala först. Och i systemarkitektur, precis som i samtal, är det ofta den som hinner först som definierar verkligheten.