Menghapus pekerja layanan yang berisi bug

Terkadang pekerja layanan yang berisi bug di-deploy, dan kemudian ada masalah. Misalnya, pekerja layanan dapat diuraikan pada saat pendaftaran dan berhasil menyelesaikan instalasi. Namun, kode yang berisi bug dalam peristiwa fetch dapat menyebabkannya tidak merespons permintaan, sehingga menghasilkan laman kosong. Kemungkinan lainnya, markup halaman di-cache secara agresif, dan pekerja layanan hanya menampilkan respons markup yang sudah tidak berlaku dari instance Cache untuk kunjungan berikutnya.

Ada banyak cara yang bisa dilakukan pekerja layanan untuk menjadi bumerang, dan itu adalah masalah yang menakutkan di situs web produksi. Meski begitu, tidak semuanya hilang. Ada beberapa cara untuk memperbaiki situasi ini dan kembali ke jalur yang benar.

Men-deploy pekerja layanan tanpa pengoperasian

Yang biasanya diperlukan untuk menangani pekerja layanan yang berisi bug adalah men-deploy aplikasi Pekerja layanan tanpa pengoperasian yang menginstal dan langsung diaktifkan tanpa pengendali peristiwa fetch:

// sw.js

self.addEventListener('install', () => {
  // Skip over the "waiting" lifecycle state, to ensure that our
  // new service worker is activated immediately, even if there's
  // another tab open controlled by our older service worker code.
  self.skipWaiting();
});

self.addEventListener('activate', () => {
  // Optional: Get a list of all the current open windows/tabs under
  // our service worker's control, and force them to reload.
  // This can "unbreak" any open windows/tabs as soon as the new
  // service worker activates, rather than users having to manually reload.
  self.clients.matchAll({
    type: 'window'
  }).then(windowClients => {
    windowClients.forEach((windowClient) => {
      windowClient.navigate(windowClient.url);
    });
  });
});

Perhatian: Tips: saat men-deploy pekerja layanan tanpa pengoperasian, pastikan bahwa URL pekerja layanan tetap tidak berubah! Jika tidak, pekerja layanan tanpa pengoperasian akan aktif bersama pekerja layanan yang berisi bug, dan masalah akan terus ada.

Pekerja layanan ini akan segera diinstal dan diaktifkan dengan memanggil self.skipWaiting() di peristiwa install. Secara opsional, kode tambahan dapat di-deploy dalam peristiwa activate untuk memuat ulang secara paksa tab terbuka lainnya dengan WindowClient yang dikontrol pekerja layanan.

Sangat penting bahwa pekerja layanan tanpa pengoperasian tidak berisi pengendali peristiwa fetch. Ketika pekerja layanan tidak menangani permintaan, permintaan tersebut melewati browser seolah-olah tidak ada pekerja layanan. Setelah pekerja layanan tanpa pengoperasian di-deploy, pekerja layanan yang berisi bug dapat diperbaiki dan di-deploy sebagai update nanti.

Pendekatan ini berhasil sebagian karena browser memiliki pengamanan yang kuat terhadap penempatan pekerja layanan di cache HTTP, dan karena browser melakukan pemeriksaan byte-untuk-byte konten pekerja layanan untuk pembaruan. Default ini memungkinkan deployment pengganti tanpa pengoperasian untuk pekerja layanan yang berisi bug untuk memperbaiki masalah dengan cepat.

Catatan: Sebagai bagian dari peluncuran pekerja layanan secara keseluruhan, Anda sebaiknya menyediakan pekerja layanan tanpa pengoperasian yang dapat ditukar jika diperlukan. Membuat perencanaan, dan memastikan bahwa semua orang di tim Anda tahu cara menangani deployment pekerja layanan tanpa pengoperasian, akan menghindari ketidakstabilan pasca-deployment.

Tindakan tambahan yang harus dilakukan

Men-deploy pekerja layanan tanpa pengoperasian harus memadai untuk menetralkan bug yang mengganggu, tetapi tindakan tambahan dapat diambil jika diperlukan.

Bagaimana jika Anda tidak mengetahui URL pekerja layanan yang lama?

Terkadang URL pekerja layanan yang diinstal sebelumnya tidak diketahui. Hal ini mungkin terjadi karena nama file tersebut memiliki versi (misalnya berisi hash dalam nama filenya). Dalam kasus ini, men-deploy pekerja layanan tanpa pengoperasian yang cocok dengan URL setiap pekerja layanan lama yang mungkin terdaftar mungkin merupakan tantangan. Hal ini bertentangan dengan praktik terbaik, karena developer kemungkinan tidak akan mengingat setiap {i>hash<i} untuk setiap versi pekerja layanan yang di-deploy.

Untungnya, header permintaan HTTP yang berguna dikirim bersama permintaan untuk skrip pekerja layanan: Service-Worker Di server web, periksa header ini dan cegat permintaan untuk melayani pekerja layanan tanpa pengoperasian. Pencapaian ini bergantung pada server web dan stack backend yang digunakan, jadi baca dokumentasi dalam bahasa yang relevan tentang cara melakukannya.

Untuk deployment pekerja layanan mendatang, tetap gunakan nama aset tanpa versi (misalnya, sw.js). Hal ini akan membuat segalanya jauh lebih mudah di kemudian hari.

Tetapkan header Clear-Site-Data

Beberapa browser akan membatalkan pendaftaran semua pekerja layanan untuk origin jika Header respons Clear-Site-Data dengan nilai 'storage' ditetapkan. Namun, ada beberapa hal yang perlu diketahui dengan pendekatan ini:

• Perlu diperhatikan bahwa tindakan ini akan menghapus semua penyimpanan untuk origin terkait. Itu termasuk localStorage, IndexedDB, sessionStorage, dan penyimpanan lainnya (tetapi bukan cache HTTP untuk origin).
• Header ini tidak didukung di semua browser.

Karena dukungan untuk {i>header<i} ini tidak menyeluruh, dukungan tersebut tidak dapat diandalkan untuk memperbaiki masalah. Oleh karena itu, sebaiknya lihat Clear-Site-Data sebagai ukuran yang perlu diambil selain men-deploy pekerja layanan tanpa pengoperasian.

Kerusakan tidak permanen

Mungkin akan terasa menakutkan apabila pengalaman pengguna terganggu oleh pekerja layanan yang memiliki bug—terutama untuk situs besar dan terkenal—tetapi kerusakan ini bersifat sementara dan dapat dipulihkan.

Jika diperlukan untuk men-deploy pekerja layanan tanpa pengoperasian untuk memperbaiki situasi ini, luangkan waktu untuk mencari tahu apa kesalahannya. Di masa mendatang, pastikan pekerja layanan hanya menangani permintaan yang diharapkan. Sering-seringlah menguji dalam staging, dan hanya deploy update jika sudah pasti.