Uji dua edge case mahal: guest tanpa login dan submit ganda. Bedah policy pending, lookup token, idempotency key, unique index, 23505, dan kelemahan jika key tidak stabil dari form.
40m bacaanKuis WajibMicro Badge Lesson
Skenario Guest & Double-Submit
Dua bug paling mahal dalam flow donasi sering tidak muncul saat demo normal.
Pertama: guest tanpa login. Banyak donatur tidak ingin membuat akun sebelum berdonasi. Sistem harus tetap bisa menerima donasi mereka, tapi jangan sampai semua data donasi bisa dibaca publik.
Kedua: submit ganda. Donatur menekan tombol dua kali, koneksi lambat, browser retry, atau request terkirim paralel. Satu niat donasi tidak boleh berubah menjadi dua tagihan.
Jadi fokus kita bukan “form sukses sekali”. Fokusnya:
text
guest sah tetap bisa donasiakses baca guest tetap sempitsatu niat donasi tetap satu row walaupun retry
Idenya benar: request kedua dengan key yang sama tidak membuat donasi baru.
Tapi ada pertanyaan penting: apakah key yang sama benar-benar dikirim saat retry?
Unique index tidak cukup kalau key selalu baru
Server action memakai fallback randomUUID() kalau form tidak mengirim idempotencyKey.
Fallback itu berguna untuk memastikan field tidak kosong. Tapi jika form tidak pernah mengirim hidden idempotency key yang stabil, setiap submit akan membuat key baru.
maka retry dari form yang sama bisa memakai key berbeda. Unique index tidak akan menolong karena tidak ada duplikasi key.
Ini pelajaran penting: idempotency bukan hanya kolom dan index. Idempotency adalah satu alur utuh dari UI → server → database.
Prompt analisis untuk Antigravity
text
Mulai dari AGENTS.md, DESIGN.md, dan docs/README.md.Tugas analisis, jangan mengubah kode dulu.Baca:- src/components/donation/donation-form.tsx- src/app/campaigns/[slug]/donate/actions.ts- src/app/donation/confirmation/[donationNumber]/page.tsx- supabase/migrations/20260829_vertical_slice.sqlAnalisis dua skenario:1. Guest donation: - policy apa yang membuat guest boleh insert donation pending? - jalur apa yang membuat guest bisa membaca confirmation tanpa SELECT bebas? - kolom sensitif apa yang tidak seharusnya keluar di guest lookup?2. Double-submit: - dari mana idempotencyKey berasal? - apakah form membuat key sekali per render dan mengirimnya sebagai hidden input? - bagaimana query existing dan unique index bekerja? - kapan error 23505 terjadi? - jika form belum mengirim key stabil, apa perbaikan minimalnya?Tulis expected vs actual untuk tiap skenario.Jangan mengubah file sampai saya menyetujui perbaikannya.
Prompt ini sengaja meminta agent memeriksa kelemahan, bukan hanya menjelaskan mekanisme ideal.
Perbaikan minimal kalau key belum stabil
Kalau hasil cek menunjukkan form belum mengirim idempotencyKey, perbaikan minimal ada di form.
Dengan begitu, satu muatan form punya satu key. Klik ulang atau retry dari niat yang sama membawa key yang sama.
Catatan: ini bukan berarti semua kasus idempotency production sudah selesai. Untuk payment gateway dan webhook, idempotency perlu desain lebih luas. Tapi untuk form submit awal, key stabil adalah langkah minimum yang benar.
Verifikasi guest
Jalankan app:
bash
npm run dev
Buka browser incognito, lalu:
buka halaman donasi campaign;
isi form valid;
submit;
pastikan redirect ke URL confirmation yang punya token;
Untuk guest, user_id biasanya null, status pending, dan lookup_token_hash terisi. Jangan membagikan nilai token atau data kontak dalam catatan publik.
Verifikasi double-submit
Setelah key stabil diterapkan, uji:
buka form baru;
submit sekali;
coba submit ulang dari state yang sama atau simulasikan request dengan key sama;
cek tabel donations.
Query:
sql
select idempotency_key, count(*)from public.donationsgroup by idempotency_keyhaving count(*) > 1;
Yang diharapkan:
text
0 rows
Cek juga jumlah row untuk key yang sama. Harus satu. Kalau ada dua row dengan key sama, unique index tidak berjalan atau key null.
23505 bukan error biasa
Kalau dua request dengan key sama tiba bersamaan, keduanya bisa lolos cek existing. Pada titik itu database yang menentukan. Request pertama insert berhasil. Request kedua kena unique violation 23505.
Di flow idempotency, 23505 bukan selalu “gagal total”. Ia bisa berarti: donasi dengan key itu sudah ada. Maka action mengembalikan reused: true.
Tapi response reused harus hati-hati. Kalau token lookup tidak tersedia saat reused, user mungkin perlu diarahkan ke halaman yang aman atau diberi instruksi jelas. Jangan membuat UX seolah sukses penuh kalau data untuk confirmation tidak lengkap.
Prinsip yang perlu dibawa
Idempotency harus stabil dari ujung ke ujung:
text
satu niat donasi → satu idempotency key → satu row donation
Tombol disabled membantu, tapi bukan pengaman terakhir. User bisa retry, jaringan bisa mengirim ulang, dan dua request bisa balapan. Karena itu lapisnya harus lengkap:
UI mengurangi klik ganda;
form mengirim key stabil;
server mengecek existing key;
database punya unique index;
23505 ditangani sebagai reused.
Checkpoint
Guest bisa insert donasi pending tanpa login.
Guest membaca confirmation lewat token hash, bukan SELECT bebas.
Token salah menghasilkan 404.
Kamu tahu apakah form mengirim idempotency key stabil.
Jika belum stabil, kamu tahu perbaikan minimalnya.
Unique index donations_idempotency_key_idx ada.
23505 dipahami sebagai race guard untuk key yang sama.
Double-submit dengan niat yang sama tidak menghasilkan dua row.
Nah, ini salah satu bagian paling “real” dari platform donasi. Yang diuji bukan happy path, tapi kondisi yang biasanya bikin sistem rusak diam-diam: guest, token, retry, dan klik ganda. Kalau kamu bisa membaca edge case seperti ini, kamu tidak lagi sekadar menyuruh AI bikin form. Kamu mulai mengendalikan alur transaksi.
Checkpoint KuisTarget: 70%
Kuis 04.4 — Skenario Guest & Double-Submit
Kuis ini wajib untuk sertifikat. Kamu tetap bisa lanjut ke pelajaran berikutnya dan mengerjakannya nanti.
text
