Kriptik stack trace'i kök neden hipotezlerine ve kontrol sırasına çevir

Ham hatayı; tek cümlelik özet, en olası 3 kök neden hipotezi ve en hızlı elenenden başlayan numaralı bir kontrol listesine çevirir.

Kanca

Ekranda 40 satırlık bir stack trace var. Nereden başlayacağını bilmiyorsun; ham mesajı arama kutusuna yapıştırıp yarım saat açık sekmeler arasında kayboluyorsun. Günün büyük kısmı zaten hata ayıklamada geçiyor.

Hamle — Claude / ChatGPT (ikisi de çalışır)

Prompt — kopyala & yapıştır

Sen deneyimli bir yazılımcısın ve şu an hata ayıklama yapıyorsun. Sana bir stack trace / hata çıktısı vereceğim. Görevin bunu tahmin bombardımanına çevirmeden, sıralı ve kontrol edilebilir bir plana dökmek.

Kurallar:
- Sadece verdiğim bilgiye dayan. Görmediğin satır numarasını, fonksiyonu veya bir kütüphanenin iç davranışını uydurma.
- Bir şeyi netleştirmek için ek bilgi gerekiyorsa, o maddenin başına "EKSİK:" yaz ve tam olarak neye ihtiyacın olduğunu söyle (hangi dosya, hangi log satırı, hangi sürüm).
- Emin olmadığın yerde "olası" / "kontrol edilmeli" de; kesin teşhis koymuş gibi yazma.
- Türkçe yaz, kısa ve düz cümle kur.

Şu formatta cevap ver:

1) TEK CÜMLE ÖZET: Hata teknik olarak ne diyor (sade dille).
2) EN OLASI 3 KÖK NEDEN: Her biri için tek satır gerekçe — stack trace'in hangi kısmı bunu düşündürüyor.
3) KONTROL SIRASI: En hızlı elenenden en pahalıya doğru numaralı liste. Her adımda: neye bakılacak + hangi sonuç çıkarsa o neden elenir veya doğrulanır.
4) İLK 5 DAKİKA: Şu an açıp bakacağım tek dosya/log ne?
5) EKSİK BİLGİLER: Kök nedeni daraltmak için benden istediklerin.

Bağlam (biliyorsan doldur, bilmiyorsan "EKSİK" bırak):
- Dil / framework ve sürüm:
- Ne zaman oluyor (her zaman / bazen / belirli bir aksiyonda):
- Son değişen şey (deploy, bağımlılık güncellemesi, config):

Stack trace / hata çıktısı:
"""
[buraya yapıştır]
"""

Çıktı

Ham hatayı; tek cümlelik özet, en olası 3 kök neden hipotezi ve en hızlı elenenden başlayan numaralı bir kontrol listesine çevirir. Sonunda elinde "önce şuraya bakacağım" diyebileceğin net bir sıra olur; birkaç dakika.

Kariyer çentiği

Panikleyip kıdemliye koşan değil, hatayı yapılandırılmış hipotezlerle karşılayan kişi ekipte "sakin problem çözen" olarak görünür.

Sınır

AI senin kod tabanını görmüyor; verdiği şey çıktıdaki metinle sınırlı bir kontrol listesi, kesin teşhis değil — ayrıca stack trace'te müşteri verisi, token veya iç sunucu adı varsa yapıştırmadan önce temizle.

Örnek — bu prompt ne üretir?

Örnek girdi

her istekte değil, daha çok öğlen yoğun saatlerde patlıyor gibi. sabah sorun yok. dün akşam ORM paketinin sürümünü yükselttik, bir de yeni bir rapor endpoint'i ekledik.

SequelizeConnectionAcquireTimeoutError: Operation timeout
    at ConnectionManager._connect (/app/node_modules/sequelize/lib/dialects/abstract/connection-manager.js:308:17)
    at ConnectionManager.getConnection (/app/node_modules/sequelize/lib/dialects/abstract/connection-manager.js:247:20)
    at async PostController.list (/app/src/controllers/postController.js:57:22)
    at async asyncHandler (/app/src/middleware/asyncHandler.js:6:5)
    at async /app/src/routes/index.js:31:5
Caused by: Error: Operation timeout
    at Timeout._onTimeout (/app/node_modules/sequelize-pool/lib/Pool.js:184:17)
    at listOnTimeout (node:internal/timers:573:17)
    at processTimers (node:internal/timers:514:7)

Çıktı

1) TEK CÜMLE ÖZET

Uygulama veritabanına yeni bir bağlantı almak için havuzda (connection pool) sıraya giriyor ama tanımlı süre içinde boş bağlantı bulamayıp zaman aşımına düşüyor.

2) EN OLASI 3 KÖK NEDEN

#	Hipotez	Gerekçe (stack trace'in hangi kısmı)
1	Bağlantı havuzu tükeniyor: açılan bağlantılar iş bitince geri bırakılmıyor (leak)	Hata `getConnection` → `Pool.js` timeout zincirinden geliyor; bağlantı yok değil, boşta bağlantı yok
2	Havuz boyutu (pool max) yükün altında yetersiz	Sadece yoğun saatte oluşması, eşzamanlı istek sayısı havuz sınırını aşınca sıranın dolduğuna işaret eder
3	Yeni rapor endpoint'i uzun/ağır sorgu tutuyor, bağlantıyı uzun süre meşgul ediyor	Dün eklenen rapor endpoint'i + `PostController.list` üzerinden gelen istekler aynı havuzu paylaşıyor olabilir

3) KONTROL SIRASI (en hızlı elenenden en pahalıya)

Havuz ayarını oku — Sequelize config'inde pool.max, pool.acquire, pool.idle değerlerine bak.

→ Değer varsayılan/düşükse (ör. max 5) ve trafik bunun üstündeyse Hipotez 2 güçlenir; makul yüksekse elenir.

Aktif bağlantı sayısını izle — DB tarafında anlık bağlantı sayısını yoğun saatte gözle (SHOW PROCESSLIST / pg_stat_activity).

→ Sayı pool.max'a yapışıp orada takılı kalıyorsa Hipotez 1 veya 2 doğrulanır.

Yavaş sorgu var mı bak — DB'nin slow query log'unu veya uzun süredir "active" duran sorguları kontrol et.

→ Aynı sorgu (özellikle rapor sorgusu) uzun süre asılı kalıyorsa Hipotez 3 doğrulanır; her sorgu hızlıysa elenir.

Sürüm değişikliğini geri sar (deneme) — ORM sürümünü eski haline alıp yoğun saatte tekrar gözle.

→ Sorun kaybolursa neden yeni sürümdeki havuz davranışı değişikliğidir; devam ederse sürüm elenir.

4) İLK 5 DAKİKA

Şu an açacağım tek yer: veritabanı bağlantı konfigürasyonunun tanımlandığı dosya (Sequelize new Sequelize(...) çağrısındaki pool bloğu). Havuz sınırlarını görmeden diğer adımlar körlemesine olur.

5) EKSİK BİLGİLER (kök nedeni daraltmak için)

EKSİK: ORM (Sequelize) ve DB sürücüsünün tam sürümü — dünkü güncellemede hangi versiyondan hangisine geçildi?
EKSİK: Mevcut pool.max ve pool.acquire değerleri (config dosyasından).
EKSİK: Yoğun saatte DB'deki eşzamanlı aktif bağlantı sayısı.
EKSİK: Yeni rapor endpoint'inin çalıştırdığı sorgu ve ortalama süresi.
NOT: "Bazen / yoğun saatte" bilgisi elimde var, o yüzden tek seferlik ağ kesintisi ihtimalini alt sıraya koydum; sürekli oluşsaydı DB erişilebilirliğini 1. sıraya alırdım.

ÜRETİM: TEM 2026 · CLAUDE Bu kayıt eşlenmiş örnek girdi ve çıktı içerir. Model koşumu kanıtı yoktur — kendi verinle doğrulamadan karar girdisi yapma.

Kendi verinle çalıştır

Verini aşağıya yapıştır; prompt seninkiyle birleşip çalıştırmaya hazır tek bloğa dönüşsün. Sonra tek dokunuşla Claude ya da ChatGPT'de aç.

Senin verin

Hazır prompt — verini bekliyor

Sen deneyimli bir yazılımcısın ve şu an hata ayıklama yapıyorsun. Sana bir stack trace / hata çıktısı vereceğim. Görevin bunu tahmin bombardımanına çevirmeden, sıralı ve kontrol edilebilir bir plana dökmek.

Kurallar:
- Sadece verdiğim bilgiye dayan. Görmediğin satır numarasını, fonksiyonu veya bir kütüphanenin iç davranışını uydurma.
- Bir şeyi netleştirmek için ek bilgi gerekiyorsa, o maddenin başına "EKSİK:" yaz ve tam olarak neye ihtiyacın olduğunu söyle (hangi dosya, hangi log satırı, hangi sürüm).
- Emin olmadığın yerde "olası" / "kontrol edilmeli" de; kesin teşhis koymuş gibi yazma.
- Türkçe yaz, kısa ve düz cümle kur.

Şu formatta cevap ver:

1) TEK CÜMLE ÖZET: Hata teknik olarak ne diyor (sade dille).
2) EN OLASI 3 KÖK NEDEN: Her biri için tek satır gerekçe — stack trace'in hangi kısmı bunu düşündürüyor.
3) KONTROL SIRASI: En hızlı elenenden en pahalıya doğru numaralı liste. Her adımda: neye bakılacak + hangi sonuç çıkarsa o neden elenir veya doğrulanır.
4) İLK 5 DAKİKA: Şu an açıp bakacağım tek dosya/log ne?
5) EKSİK BİLGİLER: Kök nedeni daraltmak için benden istediklerin.

Bağlam (biliyorsan doldur, bilmiyorsan "EKSİK" bırak):
- Dil / framework ve sürüm:
- Ne zaman oluyor (her zaman / bazen / belirli bir aksiyonda):
- Son değişen şey (deploy, bağımlılık güncellemesi, config):

Stack trace / hata çıktısı:
"""
[buraya yapıştır]
"""

Yapıştırdığın veri tarayıcından çıkmaz — WhiteYaka'ya gönderilmez. Prompt panoya kopyalanır; açılan sohbete Ctrl/⌘ + V ile yapıştırırsın.

i Bu föy örnek girdi ve çıktı içerir; yapısal doğrulama ve ölçütlü prompt koşumu henüz kaydedilmedi.

← Tüm bölümler Sıradaki föy: Bos sayfadan RFC iskeleti: baglam, secenekler, karar →

Bülten kaydı kapalı.

Bu sayfa e-posta adresi toplamaz ve liste kaydı başlatmaz. 160 hamlenin tamamı giriş yapmadan açık.