idempotency

Validasi aplikasi dan skema openapi menerima tipe baru, kolom ENUM MySQL menolaknya. Error 1265 baru terlihat saat INSERT.

TL;DR: Aplikasi mengalami error 1265 dari MySQL. Error ini disebabkan oleh perbedaan tipe data di tiga lapis yang berbeda. Perlu disinkronkan agar aplikasi berjalan lancar.

Kunci idempoten yang ikut memuat nama_panjang, supaya empat cabang FASI tidak melebur jadi satu baris.

TL;DR: Saya menulis CLI kecil untuk memindahkan data. Kunci import awalnya hanya nama dan kategori. Kemudian saya tambahkan nama panjang untuk menghindari duplikat.

Fixture hijau bukan jaminan: nested object, camelCase, dan datetime penuh baru ketahuan saat 5330 baris asli masuk ke ingest.

TL;DR: Dump JSON 5330 baris masuk mulus tanpa error, tapi kolom nama perusahaan sama tanggalnya kosong semua, ternyata mapper salah asumsi bentuk data. Field penyedia ternyata objek bersarang, kuncinya camelCase, plus tanggalnya datetime penuh yang ditolak date.fromisoformat. Setelah dibenerin, semua baris kebaca dan idempotensi jalan, pelajarannya mulai dari data asli, bukan asumsi.

Isolasi ruang kerja scraping dan pengiriman hasil lewat satu pintu API yang aman diulang: antrian resumable, kunci deduplikasi, ship-log.

TL;DR: Dulu scraping langsung nulis ke database aplikasi, pas sesi putus jadi bingung data mana yang udah masuk. Nah, commit ini mindahin semua alat scraping ke folder terpisah, hasil panen cuma boleh masuk lewat endpoint API ingest. Ada antrian kerja yang bisa dilanjutin plus kirim ulang yang aman berkat kunci dedup yang stabil, jadi idempoten dan bebas data dobel.

Pola raw dulu, parse belakangan: data mentah disimpan utuh dulu, parsing jadi proses turunan yang aman diulang saat parser berubah.

TL;DR: Scraping data dari web itu rentan mandek di tengah jalan, makanya jangan langsung parsing sambil ambil. Simpan dulu data mentahnya utuh, baru parsing terpisah lewat perintah rebuild, pakai kursor dan ledger idempoten biar bisa lanjut tanpa data dobel. Jadi kalau parser ada yang salah, tinggal perbaiki terus rebuild deh, nggak usah buka situs sumbernya lagi.

Lock yang dicek sekali di awal cuma menjaga pintu. Fencing token yang divalidasi di setiap tulisan state, plus heartbeat lease, yang menjaga datanya.

TL;DR: Cek lock sekali di awal doang nggak cukup, soalnya sesi lama bisa bangun lagi padahal lock-nya udah dicuri sesi lain. Solusinya fencing token: tiap tulis wajib bawa token yang naik terus, kalau udah basi langsung ditolak di sisi penyimpanan. Plus resume harus idempoten dan dites pakai kontrol negatif, biar guard-nya kebukti bisa gagal sebelum insiden beneran kejadian.

Mengubah aturan filter nggak harus menjalankan ulang whisper. Filter itu proyeksi dari stdout yang udah tersimpan, distamp sha256 tiap aturan berubah.

TL;DR: Ganti aturan filter kata kasar bikin penulis hampir re-run whisper buat semua file audio, padahal boros banget. Ternyata filter cuma proyeksi dari output whisper yang udah tersimpan, jadi yang diulang cukup proyeksinya aja, bukan transkripsinya. Solusinya: simpan raw output, tempel filter_version berupa hash sha256 di frontmatter, refilter selesai detikan tanpa panggil model.

Loop cron yang crash mengirim ulang prompt yang sama. Kontrak async kirim-then-poll plus dua file state bikin generate chat Qwen aman dieksekusi ulang.

TL;DR: Cron yang crash setelah prompt terkirim bikin artikel sama terkirim dua kali dan kuota gratis hangus. Solusinya cuma dua file kosong sebagai idempotency key: penanda prompt sudah terkirim dan penanda hasil sudah selesai, plus kontrak exit code untuk status antrian hingga selesai. Cron itu mesin retry alami, jadi selama state-nya bisa dicek, message broker nggak perlu.