Pemulihan Selepas Ralat dan Penyelesaian Konflik

Membuat asal penambahan optimistik dengan membuang item, atau pemadaman dengan memulihkan item, adalah mudah. Membuat asal kemas kini lebih rumit: anda mesti memulihkan nilai sebelumnya yang tepat. Jika item dikemas kini beberapa kali secara optimistik, anda mesti menjejaki setiap nilai terdahulu secara berasingan, bukan hanya keadaan asal pada pelayan.

Pertimbangkan senario ini: pelayan mempunyai item dengan nilai Z. Anda mengemas kininya secara optimistik kepada X. Semasa permintaan anda sedang diproses, pengguna lain mengemas kini item yang sama kepada Y pada pelayan. Permintaan anda tiba dan pelayan menolaknya kerana konflik. Sasaran buat asal anda ialah Z, tetapi keadaan semasa pada pelayan ialah Y. Memulihkan Z akan menulis ganti Y secara tidak betul.

Strategi paling selamat untuk membuat asal kemas kini adalah dengan mengambil semula item daripada pelayan apabila berlaku sebarang ralat mutasi, bukannya memulihkan salinan keadaan yang disimpan secara setempat. Ini menjamin bahawa keadaan pelayan yang muktamad dipaparkan, tanpa mengira perubahan serentak yang mungkin dibuat oleh pengguna lain. Pengambilan semula lebih perlahan, tetapi sentiasa betul.

API yang direka dengan baik mengembalikan HTTP 409 Konflik apabila kemas kini optimistik gagal disebabkan pengubahsuaian serentak. Isi respons biasanya merangkumi keadaan semasa pada pelayan. Pengendali ralat anda harus mengesan status 409, menggunakan isi respons untuk mengemas kini keadaan setempat dengan nilai semasa pada pelayan, dan memaklumkan pengguna bahawa perubahan mereka tidak disimpan.

Mutasi idempoten menghasilkan keputusan yang sama apabila digunakan beberapa kali. Mereka bentuk mutasi supaya idempoten, dengan menggunakan PUT dan bukannya POST, menyertakan keadaan sumber yang lengkap dan menggunakan kunci idempoten, menjadikannya selamat untuk dicuba semula apabila gagal tanpa risiko perubahan digunakan dua kali. Ini memudahkan logik buat asal dengan ketara.

Klik dua kali pada butang hantar boleh mencetuskan dua mutasi yang sama. Halang perkara ini dengan bendera isSubmitting: tetapkan bendera itu kepada true apabila mutasi bermula dan tetapkan semula apabila mutasi selesai, sama ada berjaya atau gagal. Nyahdayakan elemen pencetus apabila isSubmitting bernilai true. Ini menghapuskan mutasi pendua pada peringkat antara muka pengguna.

Untuk nyahduplikasi pada pihak pelayan, sertakan pengepala Idempotency-Key yang unik dalam setiap permintaan mutasi. Jana pengepala itu menggunakan crypto.randomUUID() apabila pengguna memulakan tindakan. Pelayan mengesan kunci pendua dan mengembalikan respons yang sama seperti permintaan asal tanpa menggunakan operasi itu sekali lagi.

Semasa mutasi sedang diproses, anda boleh memaparkan penunjuk halus bahawa keadaan optimistik belum disahkan: titik kecil yang berdenyut, teks "Menyimpan..." atau kelegapan item yang dikurangkan. Ini menyampaikan ketidakpastian tanpa menyekat interaksi. Buang penunjuk tersebut apabila berjaya atau buat asal perubahan apabila gagal.

Ralat tidak dijangka dalam logik buat asal, contohnya ketika mengakses sifat bagi nilai yang tidak ditentukan semasa memulihkan keadaan, boleh menyebabkan komponen ranap. Balut komponen yang banyak menggunakan mutasi dengan sempadan ralat supaya kegagalan buat asal yang kritikal memaparkan antara muka ralat yang baik dan bukannya skrin kosong. Catat ralat ini untuk penyahpepijatan.

Strategi pengesanan konflik yang boleh dipercayai adalah dengan menyertakan nombor versi atau ETag dalam setiap mutasi. Pelayan membandingkan versi yang dihantar oleh klien dengan versi semasanya. Jika kedua-duanya berbeza kerana kemas kini lain telah berlaku, pelayan mengembalikan status 409. Ini ialah kawalan keserentakan optimistik — anda menganggap tiada konflik, tetapi mengesannya apabila berlaku.

Logik buat asal sering tidak diuji kerana kegagalan rangkaian sukar disimulasikan. Gunakan alat seperti MSW untuk mengembalikan respons ralat dalam ujian. Tulis ujian khusus untuk: pengendalian Konflik 409, buat asal selepas tamat masa rangkaian, nyahduplikasi klik dua kali dan konsistensi keadaan selepas kegagalan. Pepijat sering tersembunyi dalam kes pinggiran ini.

Membuat asal kemas kini lebih rumit daripada penambahan atau pemadaman — sentiasa ambil semula data apabila berlaku ralat untuk mengelakkan masalah salinan keadaan yang lapuk. Konflik HTTP 409 menandakan kegagalan keserentakan optimistik; gunakan isi respons untuk memulihkan keadaan semasa pada pelayan. Reka bentuk mutasi supaya idempoten bagi membolehkan percubaan semula yang selamat. Halang pencetus berganda dengan isSubmitting dan kunci idempoten pada pihak pelayan. Uji laluan buat asal secara khusus menggunakan MSW untuk mensimulasikan ralat.