Memindahkan tugas lambat ke background boleh membuat respons API lebih cepat. Pengguna menekan hantar dan mendapat mesej berjaya, sementara e-mel atau laporan diproses kemudian. Tetapi jika kerja itu gagal tanpa amaran, “berjaya” pada skrin mungkin tidak menggambarkan hasil sebenar.
Bezakan antara permintaan diterima dan kerja selesai. Jika pengguna perlu tahu hasil akhir, sediakan status yang boleh diperiksa. Simpan ID kerja, masa mula, bilangan cubaan dan sebab gagal yang selamat dilog. Retry sesuai untuk kegagalan sementara, tetapi perlu had supaya tugas tidak menghantar e-mel yang sama berkali-kali. Reka tugas supaya ia boleh dijalankan semula dengan selamat apabila mungkin.
Uji ketika proses terhenti
Apa berlaku jika server restart selepas menerima permintaan tetapi sebelum tugas berjalan? Apakah data kerja disimpan cukup lama? BackgroundService dalam ASP.NET Core boleh menjalankan tugas hos, tetapi kerja yang mesti tahan restart mungkin memerlukan queue atau storan luaran. Panduan Microsoft tentang hosted services menerangkan asas pelaksanaannya.
Untuk tugas menghantar e-mel, tentukan apa berlaku jika proses dihentikan selepas mesej diterima tetapi sebelum e-mel dihantar. Simpan status yang boleh diperiksa dan jangan memaparkan “sudah dihantar” terlalu awal. Ujian restart yang disengajakan pada persekitaran selamat boleh mendedahkan jurang ini sebelum pelanggan menemukannya.
Kerja belakang tabir bukan kerja yang boleh dilupakan. Pengguna mungkin tidak melihat prosesnya, tetapi mereka akan melihat kesannya apabila laporan tidak sampai atau mesej dihantar dua kali.