A support után jött az igazi rendrakás: Columbia Games release-ek, jogosultságok és Game Dollars

A helyzet

A 2026. október 19-i bejegyzés arról szólt, hogyan alakítottuk át a szétszórt Columbia Games-supportleveleket ellenőrizhető feladatokká: retailer szállítás és konfiguráció, PayPal, digitális jogosultságok, PDF-ek, képcache, PostgreSQL-import és production QA. Az a nap a diagnózist, a biztonságos javításokat és a fennmaradó üzleti függőségeket tette láthatóvá. Azóta – október 19. estétől október 20. reggeléig – a hangsúly megváltozott. A következő körben már a konfigurációk közti adatszivárgási kockázatok, a felhasználóhoz kötött ajánlások, a frontendes függőségek, a túlburjánzott GitHub Actions, az egyszeri migrációk életciklusa és a Game Dollars rendelési határai kerültek sorra. Nem ugyanazt a supportlistát meséljük el még egyszer: ez a folytatás a tényleges kiadásokról és a mögöttük felépített védőkorlátokról szól.

A megoldási út

A munkát kis hatókörű PR-ekre, visszamérhető regressziókra és külön production release-ekre bontottuk. A GitHubon a main és a production előzményeit, az egyes javítások diffjeit, a lefutott CI-t és a deploy utáni QA eredményét egymástól külön kezeltük. Ahol adatmozgás történt, ott mentési és visszaállítási bizonyítékot vártunk; ahol egy backend- vagy frontendhiba volt a téma, ott célzott, adatbázist nem módosító regressziót készítettünk. Kilenc történet mutatja, hogyan lett az előző napi hibalistából rendezettebb, mérhetőbben stabil rendszer.

1. Retailer-ajánlások: a kosár nem felejtheti el, ki van bejelentkezve

A korábbi retailer-katalógusszűrés önmagában nem jelentett teljes védelmet. A belső CCM Ticket #88-nál kiderült, hogy a checkout kapcsolódó és ajánlott termékeinek cache-kulcsa főleg a kosár SKU-it figyelte. Ugyanazzal a kosárral, de más vevői identitással vagy storefront-konfigurációval így korábbi ajánlások maradhattak a képernyőn. A javítás a vevőazonosítót, a storefront scope-ot, valamint a kosár cikkeit, mennyiségeit és árait is a lekérdezés identitásához köti – mind a tizenegy storefront-változatban. Az elavult aszinkron válaszokat eldobja, a személyre szabott API-végpontok pedig `Cache-Control: private, no-store` és `Vary: Cookie` fejléceket kaptak. Izolált tesztek vizsgálták a retailer/consumer termékkört, az árakat, a hamisított scope-paramétereket és a régi kosárból kiszűrendő tételeket. A #374 javítást a #375 production release követte. A valódi retailer-böngészős átvétel továbbra is a megrendelő feladata: a sikeres automata teszt nem helyettesíti a bejelentkezett felhasználói forgatókönyvet.

2. Hârn: néhány karakter, amely mögött két renderelési útvonal állt

A belső Ticket #96 elsőre apró megjelenítési gondnak tűnt: egyes termékszövegekben a Hârn és Hârnica név helyett HTML-entitások, például `Hârn` jelentek meg. A probléma azonban nem egyszerűen egy rossz adatbázismező volt. A React szöveges renderelő és a JavaScript nélküli HTML-prerender eltérően kezelte a plain-text tartalmat. Olyan, kizárólag szöveges útvonalra korlátozott entitásdekódolás készült, amely támogatja a név szerinti és numerikus entitásokat, de nem engedi vissza a nem biztonságos HTML-t. Regressziók fedik az ékezeteket, a kombináló Unicode-karaktereket, a dupla kódolást és az escapinget. A #373 main javítást a #376 éles kiadás követte. Ez megjelenítési javítás: nem állítjuk, hogy a teljes termékadatbázist átírtuk, és a tartalomgazdai ellenőrzés ettől még indokolt.

3. Adminisztráció: rossz konfigurációban menteni sokkal nagyobb hiba, mint rossz címet mutatni

Az előző cikkben szereplő `cg/default` / `cg/retailer` kiválasztás-megőrzés után egy mélyebb probléma került elő. A checkoutszabály-szerkesztő régi formadatai saját `merchantId` és `configId` értékeket tartalmaztak. Ha az admin közben scope-ot váltott, egy későn betöltődő válasz vagy mentés visszacsempészhette a korábbi konfigurációt – éppen azt módosítva, amelyet már nem akartunk szerkeszteni. A #377 javításban a kiválasztott scope lett az utolsó, felül nem írható mentési forrás; az elavult GET-válaszokat azonosítóval szűrjük, és nem engedjük menteni a rossz scope-hoz tartozó formot. A #379 ezt külön, izolált production backportként vitte ki. A vizsgálat közben a retailer PayPal/Net 30 szállítási paritása a tesztelt négy módszernél megfelelő volt. Ugyanakkor a nulla adó vagy ingyenes szállítás nem jelent automatikus üzleti jóváhagyást: a tarifa- és adópolitikai döntés változatlanul külön kérdés.

4. Biztonsági tartozásból kontrollált dependency- és headerfrissítés

A frontend függőségeinek auditja 14 advisory-bejegyzést hozott (5 magas és 9 közepes súlyosságú, kritikus nélkül). A javítás során React Router 7.18.4-re, Vite 6.4.4-re és esbuild 0.25.12-re frissítettünk, a tranzitív csomagokkal és lockfile-lal együtt. Node 20 és Node 22 alatt tiszta telepítés, TypeScript-ellenőrzés, build és `npm audit` következett; a célzott CI-ben nulla ismert sérülékenységet jelentett az audit. A #363 javítást a #372 production release követte. Külön kezelést kapott az a statikus útvonalakon jelentkező biztonságiheader-hiány is, amelyet a #371 éles javítás és a #380 main backmerge rendezett. A headerregressziókat nem egy új, örökké futó workflow-val oldottuk meg, hanem a megmaradó ellenőrzésekhez csatoltuk. A dependencyfrissítés nem váltja ki a bejelentkezési, navigációs és checkout-felület kézi átvételét.

5. Kanadai tartományok, amerikai államok és egy valóban egyszeri adatjavítás

A címadatoknál a teljes állam- és tartományneveket normalizáló logika az új beviteli pontokon egységes kétbetűs formátumot vezetett be – beleértve a profilt, admint, importot, checkoutot és PayPal-határt. A régi értékekhez külön, védett production migráció készült. A kiadási napló három ellenőrzött adatbázis-mentést, majd egyetlen tranzakcióban 331 ügyfélhez tartozó 606 region mező javítását rögzítette (299 szállítási és 307 számlázási mező). Mindennek megmaradt a migrációs ledgerbe írt lenyomata és a korlátozott hozzáférésű visszaállítási auditja. Ezután a #370 cleanup eltávolította a már lefutott egyszeri migráció kódját és az átmeneti workflow-t, de nem a generikus futtatót, a ledgerbejegyzést, a backupot vagy a rollback-bizonyítékot. A #404 már külön dokumentálta az archiválást. Fontos különbség: a migráció egyszeri üzemi művelet, nem minden deploynál újra lefutó teszt.

6. GitHub Actions: kevesebb futás, de nem kevesebb bizonyíték

A CI-takarításnál nem egyszerűen kikapcsoltuk a kellemetlen workflow-kat. A #378/#381 sorozat öt redundáns ellenőrzést vont ki, a kapcsolódó prerender/SEO/Unicode/QA-vizsgálatokat a meglévő kapukba építette, és egyetlen post-deploy QA-folyamatot hagyott a production release után. Lighthouse-ból egy mobilos főoldalmérés fut, egy próbálkozással, helyi mérővel – nincs automatikus újrapróbálkozás, nyolcoldalas bejárás vagy PageSpeed Insights API-hívás. Egy 84/100-as eredményt mértünk, amelyet egyetlen futás pillanatképének tekintünk, nem örök teljesítménygaranciának. A korábban hibázó automatikus production→main backmerge PR-készítés jogosultsági problémáját a #382 javította dedikált tokenes/engedélyezett fallbackes megoldással és manuális retry-lehetőséggel; ezt külön sikeres workflow-futás támasztja alá. A cél: minden éles commitnál legyen megbízható ellenőrzés, de ne égesse el a GitHub Actions-kvótát a párhuzamos, már értelmetlen ismétlés.

7. Game Dollars: az egyenleg önmagában nem a rendelésre elkölthető maximum

Október 20-án a Game Dollars checkout lett a következő hangsúlyos téma. A rendelkezésre álló vásárlói egyenleg és az adott rendelés tételei alapján ténylegesen beváltható Game Dollars felső határa két külön szám. A #406 javítás a valódi, termékekhez kötött egész Game Dollars maximumot kalkulálja és validálja; a checkout felületen megjelenik a rendelésre érvényes limit, valamint a kért és ténylegesen alkalmazott pontmennyiség. A korábbi töredékes beváltási szabályt szándékosan nem írtuk át. A regressziós csomag 16 kalkulátoros határesetet és 7 offline checkout-szintű validációs esetet fed le. A tizenegy frontendváltozatnál ráadásul helyesbítettük a `CartItem.unitPrice` mezőhasználatot a nem létező `price` helyett. A lokális `make quality`, a frontendellenőrzés és a PR CI zöld eredménnyel zárt; ezután a #407 production PR merge-elve lett, a deploy és a pontos production SHA-hoz tartozó post-deploy QA pedig sikeresen lefutott. Mindez nem állítás arról, hogy valódi ügyfélpénzt vagy PayPal-tranzakciót tesztvásárlásra használtunk volna.

8. PRINT/PDF jelölők: az admin űrlap is képes üzleti adatot tönkretenni

A reggeli rendelésvizsgálat egy másik, nehezebben észrevehető hibát világított meg. Az admin termékszerkesztője egyszerű logikai checkboxként kezelte a `freebie` mezőt, miközben a szerver több lehetséges értéket használ: üres, `Y`, `PRINT` és `PDF`. Egy nyomtatott és letölthető termék mentése ezért eltüntethette a `PRINT` jelölőt, ami később hibás kedvezményhez vagy szállítási besoroláshoz vezethetett. A #405 a checkboxot explicit választóra cserélte, a PHP-s normalizálást csak megengedett értékekre korlátozta, és GET→űrlap→PUT round-trip tesztet tett a quality gate-be. A javítás bekerült a main ágba és a reggeli release-be. A korábban kifizetett megrendelést ez nem módosította; a hiányzó üzleti adat utólagos helyreállítása mindig külön, ellenőrzött művelet.

9. Takarítás: a branch, a migráció és a bizonyíték nem ugyanaz

A technikai adósságot a kiadás után sem akartuk otthagyni. A felesleges távoli feature- és agent-branch-ekből 37-et eltávolítottunk, a main/production ágakat és az aktív munkához szükséges ágakat meghagytuk. A régi, egyszeri adatbázis-migráció nem maradt a release-folyamat állandó része, de a hash-elt mentési és rollback-bizonyítékot nem dobtuk ki. Ugyanez volt az elv a CI-nál is: ideiglenes diagnosztika helyett fenntartható regression gate, felesleges futások helyett érdemi jelzés. Ettől a repository nemcsak kisebb és áttekinthetőbb, hanem a következő hibakeresésnél is könnyebben auditálható lett.

Mi lett belőle

Az előző cikk óta a retailer-ajánlások és checkout upsell identitásfüggő szűrése, a Hârn plain-text karaktermegjelenítés, az admin checkoutszabály-scope védelme, a frontend dependency audit javítása és a statikus útvonalak biztonságiheader-kezelése production release-t kapott. A region backfill bizonyítottan egyszer futott le, majd az egyszeri migráció és a felesleges CI-elemek kikerültek a napi útvonalból. A Game Dollars limitkezelés és a PRINT/PDF admin jelölők javítása a 2026. október 20-i production release-ben landolt; a deploy és az utána futó GitHub Actions QA sikeres. Az előző munkanaplóhoz képest itt már nem elsősorban feladatokat rendszereztünk, hanem azonosított határhibákat zártunk le és az üzemeltetési folyamatot egyszerűsítettük. A megrendelői valódi retailer UAT, az üzleti szállítási/adózási döntések és egyes tartalmi ellenőrzések továbbra sem tekinthetők automatikusan lezártnak.