Welke idioot heeft deze code geschreven?

Onofficiële Beta-vertaling

Deze pagina is vertaald door PageTurner AI (beta). Niet officieel goedgekeurd door het project. Een fout gevonden? Probleem melden →

Het is eindelijk gebeurd: ik heb een bug geïntroduceerd die slechts in één specifiek scenario voorkomt en niet opgelost kan worden omdat het het gevolg is van het gelijktijdig gebruiken van een oude en nieuwe versie van Oh My Posh. Wie doet dat nou, vraag je je misschien af? Nou, dit kan voorkomen als je WSL op Windows gebruikt, of virtuele machines op eender welk systeem, terwijl je dezelfde configuratie deelt tussen installaties. Geen hoofdgebruiksscenario, maar ook niet extreem zeldzaam.

Wat is er gebeurd?

Begin dit jaar, na behoorlijk wat moeite, kon ik eindelijk de belangrijkste architectuurupdate leveren sinds de herschrijving in Go. Hierdoor was een migratie van oude configuraties nodig zodat eindgebruikers niet zelf hoeven uit te zoeken wat waar gemapt moet worden - een heel logisch proces waar computers uiteraard beter in zijn.

Om dit mogelijk te maken, voegde ik een configuratie-eigenschap toe genaamd version die verhoogd kan worden wanneer de configuratie evolueert en automatisch een migratie triggert wanneer nodig. De logica om de migratienoodzaak te bepalen is als volgt:

if !env.Flags().Migrate && cfg.Version != configVersion {
    cfg.BackupAndMigrate(env)
}

Als je oplettend bent, zie je het probleem misschien al nu je het gebruiksscenario kent. Voor degenen onder ons die liever lezen dan nadenken, is het resultaat vrij rechttoe-rechtaan: de migratie draait altijd, ofwel wanneer geforceerd (omdat je handmatig oh-my-posh config migrate kunt gebruiken), ofwel wanneer de huidige configuratieversie niet overeenkomt met de vereiste versie. Eenvoudig, toch? En dit werkt zoals verwacht bij het updaten van Oh My Posh. Het probleem begint wanneer je een gedeelde configuratie hebt en meerdere versies van Oh My Posh op dezelfde machine gebruikt.

Stel je voor dat je met meerdere shells werkt: één is WSL Ubuntu met een Oh My Posh-versie die nog op versie 1 staat (S1). Op een dag update je PowerShell in Windows naar de nieuwste versie, die versie 2 gebruikt (S2). Bij het starten van S2 migreert het automatisch de configuratie naar versie 2, waarbij de template-eigenschap naar het segmentmodel wordt verplaatst.

In de praktijk wordt de volgende versie 1-configuratie:

{
  "$schema": "https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/schema.json",
  "version": 1,
  "blocks": [
    {
      "type": "prompt",
      "alignment": "left",
      "segments": [
        {
          "background": "#9A348E",
          "foreground": "#ffffff",
          "leading_diamond": "\ue0b6",
          "properties": {
            "template": "{{ .UserName }} "
          },
          "style": "diamond",
          "type": "session"
        }
      ]
    }
  ]
}

Gemigreerd naar:

{
  "$schema": "https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/schema.json",
  "version": 2,
  "blocks": [
    {
      "type": "prompt",
      "alignment": "left",
      "segments": [
        {
          "background": "#9A348E",
          "foreground": "#ffffff",
          "leading_diamond": "\ue0b6",
          "template": "{{ .UserName }} ",
          "style": "diamond",
          "type": "session"
        }
      ]
    }
  ]
}

Geweldig, geen gebruikersinteractie nodig en alles werkt zoals ontworpen. Maar stel dat je nu iets wilt doen met S1: door de logica ziet Oh My Posh dat 2 != 1 en wordt de migratie getriggerd voor versie 1. De migratie zelf is niet breaking, maar Oh My Posh herkent de template-eigenschap op segment in dit geval niet. Het eindresultaat van onze bovenstaande configuratie is behoorlijk vervelend, want we blijven achter met dit:

{
  "$schema": "https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/schema.json",
  "version": 1,
  "blocks": [
    {
      "type": "prompt",
      "alignment": "left",
      "segments": [
        {
          "background": "#9A348E",
          "foreground": "#ffffff",
          "leading_diamond": "\ue0b6",
          "style": "diamond",
          "type": "session"
        }
      ]
    }
  ]
}

😱 de template is verdwenen! Maak je nog geen zorgen, Oh My Posh gebruikt de standaardtemplate zodat je nog steeds een prompt ziet, en de migratie maakt ook een back-up van je eerder correcte versie 2-configuratie. Tot dit punt kun je nog terugdraaien - het is vervelend, maar je lokale aanpassingen zijn nog beschikbaar. Als je echter doorgaat met werken in S2 op dit moment, zal het opnieuw de migratie naar versie 2 triggeren en je back-up overschrijven met de foutieve versie 1-configuratie.

Hoewel de codefix voor dit probleem eenvoudig is, is het onmogelijk om die naar oudere versies te pushen. Gebruikers upgraden naar de nieuwste versie, en in deze specifieke opstelling kan dit problemen veroorzaken. Het advies is om alle versies in één keer te upgraden, zodat je slechts één keer migreert en er geen "oude" Oh My Posh-versie overblijft om dit ongewenste bijeffect te triggeren.

De daadwerkelijke oplossing voor dit probleem is te vinden in 7.52.1, maar om voor de hand liggende redenen werkt deze alleen bij het gaan van versie 2 naar een nieuwe configuratieversie in de toekomst.

if !env.Flags().Migrate && cfg.Version < configVersion {
    cfg.BackupAndMigrate(env)
}

Hoewel ik mijn best doe om rekening te houden met elk denkbaar edge case bij het valideren van deze logica, glippen er soms toch dingen door. Zelfs bij deze situatie vind ik het opmerkelijk dat ik deze casus niet heb overwogen, maar het is toch gebeurd. Het goede nieuws? Het zal niet meer voorkomen 😅