BAZARTY.COM (SUPABASE)

Rękodzieło to unikaty — qty równe 1 — więc dwie równoległe płatności mogły „sprzedać” ten sam egzemplarz dwa razy, a webhook Stripe przeniósłby oba zamówienia w paid. Pierwsza wersja rezerwacji (hold 15 minut na partial unique index WHERE status='active', kod 23505 jako idempotencja) wyglądała dobrze — dopiero przegląd kodu wykazał luki: holdy nie były zwalniane przy błędach (stranded holds), a samo przejście pending→paid nie miało guardu kolizji. Domknąłem to atomowym przejściem stanu w jednej transakcji RPC apply_paid_transition: lock produktów plus guard unikatu, a wykryta kolizja nie robi automatycznego refundu, tylko flaguje zamówienie needs_review z eventem double_sale_detected — pieniądze stoją, człowiek decyduje. Współbieżność rozstrzyga baza, nie klient.

Onboarding sprzedawcy kończył się statusem enabled w Stripe, a u nas payout_status wisiał na pending — sprzedawca nie mógł wypłacać. Przyczyna siedziała w niuansie Connecta: webhook platformy nie dostaje zdarzeń account.updated z kont połączonych, a w nowym Dashboardzie Stripe nie ma już przełącznika connect — endpoint z connect=true da się utworzyć wyłącznie przez API, i ma on własny, osobny sekret podpisu. Skończyło się na dwóch webhookach pod tym samym URL-em i weryfikacji podpisu przeciw obu sekretom w pętli, aż któryś się zgodzi. Do tego cała maszyna escrow: transfer release przez source_transaction, nieudany transfer cofa releasing→paid, idempotencja po processed_stripe_events, spór kupującego zatrzymuje auto-release, a backstop crona wymusza rozstrzygnięcie po 88 dniach.

Po okresie szybkiego, „klikanego” rozwoju odkryłem, że kluczowe obiekty escrow — RPC zwalniające środki, tabela zdarzeń Stripe, kolumny Connect — istnieją wyłącznie w żywej bazie produkcyjnej, a nie w wersjonowanych migracjach: baza nie była odtwarzalna z repo, a agent patrzący na kod „nie znajdował escrow”. Odzyskanie odtwarzalności zajęło kilka podejść, bo pierwszy backfill domknął główne obiekty, a audyt wykazał kolejne niezwersjonowane (payment_events, kolumny payout, funkcje RLS). Ostatecznie: migracje idempotentne (apply na żywej bazie = no-op), audyt „żywa baza vs migracje” i decyzja na piśmie, że istnieje dokładnie jedna kanoniczna baza. Lekcja o infrastructure-as-code, której nie zapomnę: schemat, którego nie ma w repo, po prostu nie istnieje.

Ten projekt to także historia zmiany metody. Zaczynał jako generatywny prototyp w Lovable — szybki, ale z regresjami, rewertami i dryfującą bazą — a skończył w dyscyplinie spec-first: pakiet planistyczny z fazami F0–F6, dziennik dwudziestu ADR-ów, pętla /loop z definicją ukończenia zawierającą code-review i security-review. Przeszedłem od generowania i klikania do mierzenia i domykania — i ta siatka bezpieczeństwa natychmiast zaczęła łapać realne błędy: przegląd kodu wykrył m.in. wyścig w debounce wyszukiwarki (flaga alive ustawiana w callbacku timeoutu zamiast w cleanupie efektu — starszy request mógł nadpisać nowsze wyniki) oraz podatność cenową, w której klient dyktował koszt wysyłki; dziś kwotę liczy serwer, wołając wycenę kuriera po swojej stronie, z bezpiecznym fallbackiem, który nigdy nie wynosi zero.