Blog

Baris media ikut terhapus bersama recordnya, tetapi file di server tetap ada. Delete permanen yang benar mengumpulkan referensi sebelum baris dihapus.

TL;DR: Di KotaPortal file media sering nyangkut di server padahal datanya udah kehapus dari DB. Makanya sekarang URL-nya dikumpulin dulu sebelum hapus, dicek di 7 kolom lewat modul mediausage Unused. Abis DB kehapus baru file yang nggak kepake dibersihin, kalau gagal hapus ya cuma di-log aja.

Temuan QA sama muncul di dua modul admin: telepon non-digit diterima. Fix: satu validator backend, mirror frontend, satu kode error 400 INVALID_PHONE.

TL;DR: Jadi gini, kolom telepon di KotaPortal lolos dimasukin huruf karena validasi cuma ada di klien, backend-nya kosong melompong. Solusinya satu fungsi allowlist di backend sebagai sumber kebenaran, terus di-mirror ke TypeScript di frontend biar error muncul inline. Libphonenumber nggak dipakai karena kegedean buat kebutuhan cek format doang.

Tujuh slug publik berisi byte kutip miring hasil impor. Perbaikannya: migrasi SQL dengan guard HEX byte-exact, down migration UNHEX, tanpa regex.

TL;DR: Jadi ada tujuh slug venue yang kebawa tanda kutip miring dari jalur impor lama, awalnya dikira kolomnya salah charset. Ternyata enggak, utf8mb3 sama utf8mb4 nyimpen karakter itu identik, berarti datanya emang rusak sebelum masuk DB. Fix-nya pakai migrasi golang-migrate dengan guard HEX biar byte-exact, rollback-nya juga balikin byte persis kayak semula.

Kegagalan API dan sesi kedaluwarsa diperlakukan sama oleh satu catch, sampai server restart meng logout semua admin sekaligus.

TL;DR: Bug satu baris bikin semua admin terlempar ke login tiap server restart, gara-gara satu catch nganggep outage sama kayak token kedaluwarsa. Solusinya simpel: purge token cuma kalau responsnya 401, sisanya ditahan pakai banner retry. Lima unit test ngunci klasifikasinya, jadi logout otomatis nggak kejadian cuma karena server sempat down.

Satu string ALL dari middleware diperlakukan sebagai nilai kolom, dan daftar pengumuman kehilangan seluruh record ber-bidang.

TL;DR: Ada bug seru: super admin malah dapat daftar pengumuman kosong, padahal datanya aman di database. Ternyata scope ALL dari middleware dikira nilai bidang biasa sama repository, plus baris global yang NULL memang gak bakal kena perbandingan "=" biasa. Fix-nya gampang, ALL dianggap tanpa-filter terus tambah IS NULL di query, dikunci pake regression test.

Empat laporan QA jadi satu tabel induk: 18 menunggu keputusan, 4 tak terulang. Keputusan owner lebih menentukan dari umur tiket.

TL;DR: Empat laporan QA bikin pusing karena semuanya kerasa mendesak. Solusinya cuma satu file FINDINGS.md isinya tabel: 18 nunggu keputusan owner, sisanya selesai, tidak terulang, atau malah bukan bug. Prioritas diurutkan dari risiko, bukan umur tiket, jadi yang bahaya dikerjain duluan, sisanya nyusul.

Toast email sudah dipakai muncul bahasa Inggris di UI Indonesia. API benar pakai kode status RFC; yang gagal lapisan penerjemahannya.

TL;DR: Jadi pas test form tambah user, pesan error "email already in use" muncul dalam bahasa Inggris mentah. Ternyata API-nya nggak salah, malah bener banget pakai kode status RFC kayak 409 buat konflik; yang keliru cuma frontend yang nggak nerjemahin ke bahasa Indonesia. Sisanya aman sih, cuma ada satu bug file yatim pas hapus via entitas induk.

Sesi QA modul wisata: tombol hapus lewat skrip membuat dialog konfirmasi native langsung hilang, penghapusan dibatalkan diam-diam.

TL;DR: Tombol hapus di wisata kelihatannya mati, ternyata dialog confirm otomatis di-dismiss Playwright karena nggak ada handler dialog; lewat MCP pakai browser_handle_dialog aman. Dua temuan QA, validasi telepon dan media orphan, akar masalahnya sama dengan modul announcement, jadi dilipat jadi satu keputusan owner lintas modul. Semua hasil diverifikasi langsung ke database dan file, bukan cuma lihat UI.

Format laporan QA dua lapis: laporan sesi append-only log-as-you-go plus berkas modul living, dengan angka hanya dari artefak mesin.

TL;DR: Jadi ceritanya, laporan pengujian sering nggak bisa dipercaya karena angkanya cuma diketik ulang dari ingatan, bukan dari bukti asli. Solusinya: catat sesi sambil jalan (append-only) plus berkas modul yang terus di-update, semua angka wajib dari artefak mesin. Hasilnya, 31 skenario keuji, temuan gampang dilacak balik, nggak ada lagi rekonstruksi di akhir hari.