Pengembalian saat Kesalahan dan Penyelesaian Konflik

Mengembalikan penambahan optimistis dengan menghapus elemennya atau mengembalikan penghapusan dengan memulihkan elemennya cukup sederhana. Mengembalikan pembaruan lebih rumit: Anda harus memulihkan nilai sebelumnya yang persis. Jika elemen diperbarui beberapa kali secara optimistis, Anda harus melacak setiap nilai sebelumnya secara terpisah, bukan hanya status awal dari server.

Pertimbangkan skenario berikut: server memiliki elemen dengan nilai Z. Anda memperbaruinya secara optimistis menjadi X. Saat permintaan Anda masih berlangsung, pengguna lain memperbarui elemen yang sama menjadi Y di server. Permintaan Anda tiba dan server menolaknya karena konflik. Sasaran pemulihan Anda adalah Z, tetapi status server saat ini adalah Y. Memulihkan Z akan menimpa Y secara keliru.

Strategi pemulihan yang paling aman untuk pembaruan adalah mengambil ulang elemen dari server setiap kali terjadi kesalahan mutasi, bukan memulihkan cuplikan yang disimpan secara lokal. Dengan begitu, Anda selalu menampilkan status resmi dari server, terlepas dari perubahan serentak yang mungkin dilakukan pengguna lain. Pengambilan ulang memang lebih lambat, tetapi selalu benar.

API yang dirancang dengan baik mengembalikan HTTP 409 Konflik ketika pembaruan optimistis gagal karena perubahan serentak. Isi respons biasanya menyertakan status server saat ini. Penanganan kesalahan Anda harus mendeteksi 409, menggunakan isi respons untuk memperbarui status lokal dengan nilai server saat ini, dan memberi tahu pengguna bahwa perubahan mereka tidak disimpan.

Mutasi idempoten menghasilkan hasil yang sama saat diterapkan beberapa kali. Merancang mutasi agar idempoten, misalnya dengan menggunakan PUT, bukan POST, menyertakan status sumber daya secara lengkap, dan menggunakan kunci idempotensi, membuat percobaan ulang setelah kegagalan menjadi aman tanpa risiko menerapkan perubahan dua kali. Hal ini sangat menyederhanakan logika pemulihan.

Klik ganda pada tombol kirim dapat menjalankan dua mutasi yang identik. Cegah hal ini dengan penanda isSubmitting: atur menjadi aktif saat mutasi dimulai, lalu atur ulang saat mutasi selesai, baik berhasil maupun gagal. Nonaktifkan elemen pemicu saat isSubmitting sedang aktif. Cara ini menghilangkan mutasi duplikat pada tingkat antarmuka pengguna.

Untuk deduplikasi di sisi server, sertakan header Idempotency-Key yang unik dalam setiap permintaan mutasi. Buat kunci tersebut dengan crypto.randomUUID() saat pengguna memulai tindakan. Server mendeteksi kunci duplikat dan mengembalikan respons yang sama seperti permintaan asli tanpa menerapkan ulang operasi.

Selama mutasi berlangsung, Anda dapat menampilkan indikator halus bahwa status optimistis belum dikonfirmasi: titik kecil yang berdenyut, teks "Menyimpan...", atau opasitas elemen yang dikurangi. Ini menyampaikan ketidakpastian tanpa menghambat interaksi. Hapus indikator setelah berhasil atau pulihkan status saat terjadi kegagalan.

Kesalahan tak terduga dalam logika pemulihan, misalnya mengakses properti dari nilai yang tidak terdefinisi saat memulihkan status, dapat membuat komponen mogok. Bungkus komponen yang banyak melakukan mutasi dengan batas kesalahan agar kegagalan pemulihan yang fatal menampilkan antarmuka kesalahan yang baik, bukan layar kosong. Catat kesalahan ini untuk penelusuran kesalahan.

Strategi deteksi konflik yang andal adalah menyertakan nomor versi atau ETag dalam setiap mutasi. Server membandingkan versi yang dikirim klien dengan versinya saat ini. Jika keduanya berbeda, yang berarti pembaruan lain telah terjadi, server mengembalikan 409. Ini adalah kontrol konkurensi optimistis—Anda mengasumsikan tidak ada konflik, tetapi mendeteksinya saat terjadi.

Logika pemulihan sering tidak diuji karena kegagalan jaringan sulit disimulasikan. Gunakan alat seperti Mock Service Worker (MSW) untuk mengembalikan respons kesalahan dalam pengujian. Tulis pengujian eksplisit untuk: penanganan Konflik 409, pemulihan setelah waktu tunggu jaringan habis, deduplikasi klik ganda, dan konsistensi status setelah kegagalan. Kasus tepi inilah tempat cacat sering tersembunyi.

Kode status HTTP apa yang dikembalikan API yang dirancang dengan baik ketika pembaruan optimistis gagal karena perubahan serentak oleh pengguna lain?

Pemulihan pembaruan lebih rumit daripada penambahan atau penghapusan—selalu ambil ulang saat terjadi kesalahan untuk menghindari masalah cuplikan yang sudah usang. HTTP 409 Konflik menandakan kegagalan konkurensi optimistis; gunakan isi respons untuk memulihkan status server saat ini. Rancang mutasi agar idempoten supaya percobaan ulang aman. Cegah pemicu ganda dengan isSubmitting dan kunci idempotensi di sisi server. Uji jalur pemulihan secara eksplisit menggunakan MSW untuk menyimulasikan kesalahan.