Súhrnný balík opráv — dvojhodinový výpadok synchronizácie, odhlásenie po zaplatení, Grandus importy
· Infraštruktúra
Konsolidovaný balík opráv za obdobie 4. 8. – 13. 8. 2026. (1) Synchronizácia dodávateľov stála dve hodiny bez akéhokoľvek upozornenia (0fa5275a, ae782a67, 18fe3cb5) — 11. 8. 2026 sa synchronizácia zastavila na celej platforme, kým sa procesor hlásil ako zdravý. RabbitMQ ukončil kanál konzumenta pre vypršanie potvrdenia doručenia a TCP spojenie nechal otvorené; procesor sledoval len spojenie, nikdy sa teda nepripojil nanovo a fronta importov narástla na 10 391 správ s nula konzumentmi. Opravené sú štyri nezávislé chyby: zatvorenie kanála eskaluje na cestu opätovného pripojenia, prefetch klesol zo štvornásobku počtu workerov na ich počet a timeout na strane brokera stúpol z 30 min na 3 h, heartbeat priebehu zabránil päťminútovému watchdogu zabíjať zdravé veľké importy (feed s 21 913 produktmi zlyhal v 25 z 26 behov) a všetkých osem chybových ciest zapisuje čas synchronizácie, čo predtým hnalo každého dodávateľa do behu každých ~31 minút bez ohľadu na nastavený interval. Druhé kolo oddelilo prah zastaraného importu na 90 minút a opravilo availability feedy SFTP dodávateľov, ktoré padali na každom tiku. (2) Grandus importy hlásené ako zlyhané a všetka ich práca zahodená (17ba93c4) — 66 zo 196 zlyhaných importov na platforme (34 %), z toho 7 z 9 behov jedného tenanta za jediný deň, bol watchdog rušiaci zdravé behy — a zrušený beh zahodil aj to, čo už mal zapísané: beh zrušený pri dávke 10 400 sa zalogoval ako zlyhanie s 0 produktmi. Každá cesta zrušenia teraz vracia čiastkový výsledok s rozsahom dávok a presnými počítadlami (nezapísaná dávka sa odpočíta, kým predtým sa report vedel pomýliť o celú dávku), a hláška ovládača o už uzavretej transakcii sa považuje za ten istý watchdog len vtedy, keď bol kontext importu naozaj zrušený. (3) Zaplatil a o pár sekúnd skončil na prihlasovacej obrazovke (d1489d20, a5f836d9, 4647efad, 80c83850, abccb249) — autentifikačné cookies mali sameSite strict, ktoré sa pri návrate z platobnej brány neposielajú, takže aplikácia naštartovala neprihlásená a sama sa odhlásila; teraz sú lax, pri cross-site POST a v rámoch sa naďalej nepošlú. V tom istom toku: platobná stránka si znova pýtala e-mail zadaný pri registrácii (zákaznícky záznam vznikal bez neho), prvonákupca sa vracal na záložku fakturácie namiesto aplikácie, kde sa spúšťa onboarding, a zľavový kód držaný z registrácie sa na kartách balíčkov vôbec neukázal. Pri zapnutom automatickom výpočte dane odmietne poskytovateľ otvoriť reláciu, ak je jeho daňové nastavenie v danom režime neúplné — z tlačidla „Kúpiť" sa stala holá chyba servera, dnes je z nej čitateľná veta pre zákazníka a poskytovateľova vlastná správa s odkazom pre operátora. A chybové hlášky pri registrácii a prihlásení sa už mapujú zo strojového kódu, nie zo servera: slovenská stránka vypisovala „email must be an email", obsadené meno firmy tvrdilo zákazníkovi, že jeho e-mail je už registrovaný, a zamknutý účet, pozastavená firma aj používateľ bez firmy hlásili „nesprávny e-mail alebo heslo". (4) Ročné predplatné zaznamenané ako mesačné (063b8cae) — produkčný webhook platobného poskytovateľa je pripnutý na staršiu verziu API, ktorá predchádza súčasnému formátu cien, takže prichádzajúce udalosti niesli starší názov poľa. Čítal sa len ten nový, interval preto pri každom doručení spadol na predvolený mesačný — zákazník platiaci 249,90 € ročne bol vedený ako mesačný predplatiteľ — a zmena balíčka vykonaná v portáli poskytovateľa sa uplatnila ako „bez zmeny", takže firme ostali nároky, za ktoré už neplatí. Čítajú sa teraz obidva tvary poľa, čo je pri opakovaných cenách presná, nie približná náhrada. (5) Firmy s darovaným balíčkom si zamykali účet a boli tlačené kúpiť, čo už dostali (7dd44dae, 226a65dc) — každá cesta, ktorá udelí balíček zadarmo, nechávala dátum splatnosti na hodnote z registrácie, a keďže taká firma nemá predplatné, presne vyhovovala pravidlu sweepu: platforma by účet zamkla týždeň po tom, čo mu balíček darovala — pri kupóne v registrácii, kupóne na ďalšej firme aj pri udelení z helpdesku. Kupón na voľné obdobie navyše neoznačil balíček ako zvolený, takže zákazníka to poslalo na výber balíčkov, kde má každá karta tlačidlo na kúpu za plnú cenu a poistka proti duplicitnej kúpe nemôže zabrať pri firme, ktorá nikdy predplatné nemala; dokončenie takej platby navyše uzavrelo živý dar ako nahradený. Opravené na oboch stranách — pečiatka voľby aj odmietnutie predaja firme, ktorá už na darovanom balíčku je. (6) Produkty ostali skryté pre e-shop aj ERP po ručnom hľadaní duplicít (d6023f0c) — zákazník sa pýtal, prečo záložka „Prepojené duplicity" drží každý riadok z jeho ručného hľadania. Živili to tri chyby: návrh z ručného hľadania ukladal ako členov obe strany, takže po jeho aplikovaní sa produkty strany A stali duplicitami navzájom, čo odporuje pravidlu obrazovky „strana A je primárna"; nič nebránilo tomu, aby bol produkt naraz primárny aj sekundárny, takže opätovné spustenie hľadania s vymenenými stranami zapísalo zrkadlový odkaz a skrylo OBA produkty pred e-shopom aj ERP pushom (620 zrkadlených riadkov / 310 zamrznutých produktov u tenanta, ktorý to nahlásil); a odstránenie odkazu nikdy nevyčistilo ukazovateľ na produkte, lebo ho porovnávalo s nesprávnym id — odkaz zo záložky zmizol, no produkt ostal skrytý bez akejkoľvek možnosti odpojenia. Mazanie a čistenie sú teraz jeden atomický príkaz a spoločné pravidlo stráži všetky tri zápisové cesty vrátane jednej hromadnej dávky. (7) „Produkt sa nenašiel" pri produkte, ktorý existoval (331e45b1) — otvorenie produktu hneď po dobehnutí automatizácie hlásilo, že produkt neexistuje. Zmazaný nikdy nebol: detailový dopyt načítaval 16 relácií stratégiou join, čo pri nahlásenom produkte (144 kategórií × 11 dodávateľských kategórií × 2 ceny × 8 príloh) znamená 25 344 riadkov, nameraných na 213 MB a 18,2 s proti 30-sekundovému klientskemu timeoutu — a 15 050 z 15 072 produktov tohto tenanta nesie viac než 100 kategórií. Ten istý dopyt so stratégiou po reláciách vracia výsledok za 31 ms, poradie relácií je explicitne určené a obrazovka odteraz rozlišuje skutočnú 404 od timeoutu, chýbajúceho oprávnenia a chyby servera, každú preloženú a s ponukou opakovania. (8) Grandus: zastarané a zdvojené parametre, duplicitné varianty a nesprávny kód produktu (0357b35d, b2f6da46) — Grandus feedy nemali vôbec cestu na mazanie parametrov: parameter vypadnutý z feedu si držal riadok navždy a zmenená hodnota pridala druhý riadok, takže produkt ukazoval starú aj novú hodnotu (nasucho zmeraných 28 166 zastaraných riadkov u 23 734 produktov a piatich dodávateľov, z toho 17 917 riadkov parametra, ktorý vo feede nie je od marca). Parametre sa teraz prečisťujú pri každej synchronizácii, párované v surových feedových pojmoch a ohraničené tak, aby sa hodnoty od AI, ručne zadané, vytvorené pravidlom ani skopírované zlúčením nikdy nedotkli. Hlásenie „dva varianty, zlý kód produktu" malo tri príčiny naraz: varianty sa hľadali podľa dodávateľského SKU, ktoré dodávateľ vie zmeniť, kód produktu sa po prvom importe nikdy neaktualizoval (85 produktov u 13 dodávateľov na produkcii), a varianty založené pred júlom nemajú stabilný identifikátor, takže ich sweep deaktivácie nikdy nevidel (50 934 aktívnych variantov). Varianty sa teraz kľúčujú na stabilný identifikátor, kód sa obnovuje pri každej synchronizácii a konzervatívny backfill opraví, čo sa opraviť dá jednoznačne. (9) Text z editora sa v e-shope vykresľoval ako jedna súvislá stena (d854b02b) — články blogu, CMS stránky, blok na domovskej stránke, dlhé popisy kategórií aj záložka s popisom produktu vykresľujú HTML napísané v administrácii cez štýlovacie triedy, ktoré v e-shope nikdy neboli nainštalované, a CSS reset navyše zobral okraje nadpisom, odsekom, zoznamom aj citáciám — celý tento obsah sa tak zlial do jedného bloku. Typografia je teraz nainštalovaná a naviazaná na farby konkrétneho e-shopu, takže odkazy v článkoch preberajú akcent tenanta; ošetrené sú aj menšie nadpisy, prázdne položky zoznamu vyrobené editorom, príliš veľké obrázky a široké tabuľky.