Engineering

Engineering

Hoe Mythex wordt gebouwd en gedraaid, inclusief wat er kapotging en hoe we het oplosten.

• Een mislukte herpublicatie verwijdert nooit een werkende backend — Een mislukte herpublicatie kon de live API van een app wissen of een kapotte versie laten draaien. Drie fixes voor hoe Mythex een mislukte publicatie terugdraait.
• Meldingen die één keer afgaan, niet één keer per server — Een dagelijkse melding bereikte ons vijf keer op één middag. Waarom deduplicatie in het geheugen faalt met twee servers en een deploy, en hoe gedeelde opslag het oploste.
• Overstappen naar grotere werkruimtes zonder dat iemand hoeft te wachten — Een kwart van onze werkruimtes bleef op 1 GB nadat we naar 2 GB overstapten. Onze eerste fix liet één persoon zeven minuten wachten. Wat we veranderden.
• Databases factureren op basis van wat ze daadwerkelijk gebruiken — We schatten vroeger de databasekosten van elke app, en die schatting was aan beide kanten fout. Nu wordt elke database gefactureerd op gemeten gebruik, uur voor uur.
• Apps opvangen die direct na publiceren crashen — Drie publicaties slaagden voor de health check terwijl hun API bij elke start crashte. De oorzaak: crashes tellen in een lijst die maar vijf events bewaart.
• Agentbeurten met veel afbeeldingen binnen het geheugen houden — Een agentbeurt die catalogusscans bleef bekijken liep vast op 952 MB geheugen. Drie aparte oorzaken die afbeeldingen te lang vasthielden, en hoe we ze hebben opgelost.
• Lange agentbeurten binnen het contextvenster houden — Subagents groeiden tot het model ze weigerde, stopten vroeg om ruimte te sparen of telden Russische tokens verkeerd. Drie fixes waardoor lang AI-werk afrondt.
• De chat in leven houden als een telefoon slaapt — Telefoons slapen, wisselen van tabblad en verliezen het netwerk midden in een build. Twee bugs lieten de chat vastlopen of een half antwoord tonen. Zo fixten we ze.
• Hoe één zware chat onze API omver kon halen — Op 28 september liepen beide API-servers tegelijk vol geheugen. De eerste fix was meer geheugen; de echte was chatgeschiedenis laden op grootte, niet op aantal.
• Twee keer op Publish drukken publiceert nu één keer — Drie publicatieverzoeken voor één app startten elk een deploy. Nu beslist de database wie publiceert, en de anderen krijgen een eerlijk bericht.
• SEO-lessen uit het repareren van onze eigen site — Dubbele FAQ-markup, de verkeerde miniatuur in Google, sjabloonpagina's die niemand aanklikte en een pad dat onze edge weigerde. Wat we vonden op mythex.ai en oplosten.
• Statische sites blijven online terwijl ze opnieuw worden gepubliceerd — Een statische site opnieuw publiceren leegde de live site eerst. Nu blijft de oude versie online tot de nieuwe klaarstaat, en zijn wijzigingen binnen seconden zichtbaar.
• De out-of-memory-crash verborgen in een voortgangslabel — Onze AI-agent liep vast op geheugen bij het schrijven van één groot bestand. De oorzaak was een statuslabel dat 41.000 keer opnieuw werd verstuurd.
• Het ontbrekende swapbestand dat onze servers liet vastlopen — Een productieserver reageerde niet meer zonder te crashen: thrashing op een machine zonder swap. Wat er gebeurde en wat we veranderden.
• Databases wakker maken zonder dode verbindingen — Een gepubliceerde app hield het eerste verzoek na een wake-up 10 tot 12 seconden vast op dode databaseverbindingen. Nu is het 2,3 seconden.
• We beperkten onze eigen services met rate limits — De per-adres rate limit van onze API behandelde onze eigen services als één drukke persoon, en in productie kregen ze 429's. Hoe we het vonden en oplosten.
• Waarom we de servers van Mythex naar ARM verhuisden — Toen het zware werk naar sandboxes verhuisde, gebruikten onze servers een derde van hun geheugen. Kleinere ARM-instanties verlaagden de kosten met ruwweg 30%.
• Hoe we deploys terugbrachten naar nul 502-fouten — Een watchdog die tegen onze deploys racete, en een load balancer die te laat merkte dat een server stopte. Zo brachten we deploys van 10 502's naar nul.