Menjaga Chat Tetap Hidup Saat Ponsel Tidur

Agen Mythex bisa bekerja bermenit-menit untuk satu permintaan, dan Anda mungkin sedang memantaunya dari ponsel, yang terkunci, berpindah aplikasi, dan berganti jaringan selama proses itu. Dua bug membuat hal ini bermasalah. Pada bug pertama, chat menganggap setiap sinyal “halaman terlihat lagi” sebagai bukti bahwa koneksinya sudah mati, lalu terus mengulang sampai berhenti di “Connecting…”. Pada bug kedua, ponsel yang tertidur saat balasan pertama dari chat baru sedang berjalan kembali hanya dengan beberapa potongan pertama balasan itu, sampai halaman di-refresh secara manual. Keduanya sudah diperbaiki.

Bagaimana chat mengikuti giliran yang sedang berjalan

Saat agen bekerja, chat membuka stream dari server kami: setiap langkah, yaitu pemikiran, panggilan tool, atau potongan balasan, datang sebagai event. Jika stream terputus, chat menyambung ulang dan server memutar ulang event terbaru dari buffer yang menyimpan 120 detik terakhir. Saat giliran berakhir, chat juga meminta riwayat tersimpan dari server dan mencocokkan apa yang sudah ditampilkan dengan apa yang tersimpan. Langkah terakhir itu menangkap apa pun yang terlewat oleh stream.

Untuk membedakan koneksi yang hidup dari yang mati saat tidak ada yang terjadi, server mengirim “ping” kecil setiap 15 detik.

Bug 1: bangun dari tidur mematikan stream yang sehat

Browser memberi tahu halaman saat halaman itu terlihat kembali: setelah berpindah tab, setelah layar dibuka kuncinya. Kami memakai itu sebagai isyarat untuk memeriksa koneksi, dan dalam praktiknya, untuk membatalkan stream dan menyambung ulang, dengan anggapan stream sudah mati saat tersembunyi.

Di ponsel dan browser yang tertanam, event ini terjadi jauh lebih sering daripada stream yang benar-benar mati: setiap perpindahan tab, setiap buka kunci, dan di beberapa browser tertanam hampir setiap beberapa detik. Setiap kali, stream yang sehat dibatalkan. Chat menyambung ulang, memutar ulang, dibatalkan lagi, lalu berhenti di “Connecting…”. Kemudian ia menampilkan bahwa giliran sudah berakhir padahal agen masih bekerja.

Perbaikan: nilai stream dari apakah ia masih berkomunikasi

Chat sekarang mencatat kapan stream setiap proyek terakhir menerima sesuatu, baik event maupun ping setiap 15 detik. Sinyal “terlihat lagi” hanya membatalkan stream yang sudah diam selama 25 detik: lebih lama daripada interval ping ditambah satu lompatan jaringan yang lambat, sehingga stream yang hidup tidak pernah memenuhi syarat. Tes memastikan bahwa ping dihitung sebagai tanda kehidupan, dan stream yang baru saja mengirim ping tidak dianggap mati.

Aturan yang kami ambil dari sini: visibilitas halaman menyatakan sesuatu tentang halaman, bukan tentang koneksi jaringan. Tanyakan pada koneksinya.

Bug 2: separuh balasan setelah ponsel bangun

Bug ini bisa kami reproduksi setiap kali di simulator iOS:

1. Mulai chat baru dan kirim permintaan yang membutuhkan waktu.
2. Biarkan ponsel tidur selama proses membangun.
3. Kembali setelah giliran selesai dan buffer replay dua menit sudah kedaluwarsa.

Chat menampilkan beberapa blok pertama balasan, ditandai sebagai selesai, dan tetap begitu sampai Anda me-refresh halaman.

Penyebabnya

Chat baru belum punya thread, yaitu percakapan tersimpan, sampai pesan pertama membuatnya. Itu terjadi di dalam fungsi kirim, setelah kirim sudah mengambil langkah rekonsiliasi, yang masih mengira belum ada thread. Jadi di akhir giliran pertama dalam chat baru, rekonsiliasi tidak melihat thread dan diam-diam kembali tanpa meminta apa pun.

Biasanya tidak ada yang sadar, karena stream sudah mengirim seluruh giliran itu. Tetapi ponsel yang tertidur selama giliran berlangsung dan kembali setelah buffer replay 120 detik kedaluwarsa tidak bisa mendapatkan event yang hilang dari stream, dan rekonsiliasi yang seharusnya mengisi celah itu tidak pernah berjalan.

Perbaikannya

• Kirim memberi tahu rekonsiliasi thread mana giliran itu milik, sehingga giliran pertama di chat baru direkonsiliasi seperti giliran lainnya. Jika Anda sudah membuka chat lain saat jawabannya kembali, hasilnya dibuang, bukan ditampilkan di tempat yang salah.
• Rekonsiliasi yang gagal dicoba lagi. Ponsel yang bangun di koneksi buruk bisa mendapati giliran sudah selesai lalu gagal mengambilnya. Kejadian itu sekarang diingat, dan chat meminta lagi saat tab ditampilkan kembali atau jaringan kembali.
• “Worked for” dibuat jujur. Setiap balasan menampilkan berapa lama agen bekerja. Jika tab tidak pernah melihat pesan akhir giliran dari server, dulu durasinya diisi dari jam tab sendiri, yang berjalan dari saat Kirim sampai ponsel bangun, termasuk waktu saat ditinggal. Angka itu sekarang ditandai sebagai perkiraan, dan diganti dengan durasi tersimpan begitu riwayat tiba.

Apa yang kami pelajari

• Uji di perangkat yang benar-benar dipakai orang, dengan cara mereka memakainya. Kedua bug ada di celah antara “stream yang bekerja” dan “ponsel di dalam saku”.
• Fallback yang tidak pernah berjalan bukanlah fallback. Langkah rekonsiliasi ada persis untuk kasus ini, dan diam-diam dilewati.
• Coba ulang juga pemulihannya. Saat ponsel bangun sering kali justru saat koneksinya sedang paling buruk.
• Jangan tampilkan tebakan sebagai fakta. Durasi dari jam yang salah lebih buruk daripada tidak ada sama sekali; beri label, atau ganti.

Pekerjaan yang sama juga merapikan beberapa hal yang akan Anda lihat saat giliran berjalan: langkah shell diberi label menurut perintah yang melakukan pekerjaan, bukan cd; screenshot di chat mempertahankan bagian kiri atas halaman dan muat di kolom; dan proyek baru mengambil nama yang dibuat otomatis tanpa perlu refresh.

Jika Anda membangun aplikasi sendiri untuk ponsel, panduan kami tentang cara membangun aplikasi web yang ramah ponsel dan aplikasi native vs progressive web app membahas dasarnya. Lebih banyak tentang chat itu sendiri ada di dokumentasi chat.