· kaynak dev.to (home feed)
Telegram'ın username alanı, bir sohbette birden fazla handle bulunduğunda boş bir string döndürüyor
Bir dev.to yazısı, birden fazla public handle barındıran sohbetlerde Telegram'ın boş bir username string'i döndürdüğünü gösteriyor; bu da naive t.me link oluşturmayı bozuyor. Çözüm, aktif ve düzenlenebilir olan handle'ı kullanmak.

dev.to'da yayınlanan bir yazı, handle tabanlı link oluşturmayı sessizce bozabilecek bir Telegram API tuzağını belgeliyor: username alanı, platformun kurucusunun hesabında bile boş bir string olarak geri gelebiliyor.
Yazının merkezindeki örnek, 16 Eylül 2026'da canlı çıktı olarak yakalanan durov hesabı. Yanıt bir sayısal id (1006503122) ve username: "" taşıyor — null değil, eksik de değil. Bulduğu her şeyle link oluşturan kod, chat.username or chat.id gibi bir şey aracılığıyla t.me/1006503122 üretiyor; bu URL düzgün görünüyor ama insan okuyucu için hiçbir işe yaramayan bir adrese çözümleniyor.
Tek endpoint'ten iki biçim
Yazıya göre bu bir bug değil. Telegram bir sohbetin aynı anda birden fazla public handle barındırmasına izin veriyor ve böyle bir durumda birincil username alanı boşalıyor, handle'lar her biri kendi flag'lerini taşıyan ayrı bir usernames dizisine taşınıyor.
durov için bu dizi altı handle tutuyor: durov, rove, paul, snow, feed ve lean. Altısı da aktif olarak işaretlenmiş ve tam olarak biri — durov — ayrıca düzenlenebilir olarak işaretlenmiş. Tek handle'lı bir sohbet ayna görüntüsü biçimi gösteriyor: telegram kanalı için bir sorgulama username: "telegram" ve usernames: null döndürüyor. Her iki yanıt da aynı route'tan geliyor ve yazının kesin sonucu şu: iki biçimden yalnızca birini ele alan kod, yarısı yanlış oluyor.
Kanonik handle'ı seçmek
Sezgisel kural — ilk aktif girdiyi almak — yanlış olan kural, diyor yazı. Düzenlenebilirlik ayırt edici bit: sahibin kontrol ettiği handle'ı işaret ediyor, diğer girdiler ise çözümlenen ama kanalın adı olmayan takma adlar. Sayısal flags değeri aynı bilgiyi kodluyor (yalnızca aktif için 2, aktif artı düzenlenebilir için 3), ancak boolean'lar bu bilgiyi zaten ortaya koyuyor, yani deşifre edilecek bir şey yok.
Önerilen çözüm sırası şöyle: önce aktif ve düzenlenebilir girdi, sonra herhangi bir aktif girdi, sonra düz username alanı, sonra vazgeçmek:
python def best_handle(chat): names = chat.get("usernames") or [] for entry in names: if entry.get("active") and entry.get("editable"): return entry["username"] for entry in names: if entry.get("active"): return entry["username"] return chat.get("username") or None
Bu biçimdeki iki ayrıntı önemli. or [] koruması, tek handle'lı sohbetlerde usernames'in boş değil null olduğu için var; doğrudan üzerinde gezinmek çoğu durumda exception fırlatıyor. Ve iki geçiş bu sırada kalmalı — tek bir döngüde birleştirmek, bir takma ad önce geldiğinde onu döndürüyor.
Son None da önemli. Sayısal id'ye geri düşmek geçerli görünen ama hiçbir yere gitmeyen bir link üretiyor; yazı bunu hiç link olmamasından daha kötü buluyor.
Pratikte nerede bozuluyor
Hata, saklanan verinin tekrar linke dönüştürüldüğü her yerde ortaya çıkıyor: kanalları listeleyen özet e-postaları, panel satırları, haftalar sonra açılan CSV export'ları. Tetikleyici, eski handle'larını canlı tutarken adını değiştiren bir kanal — tam olarak username'in boşaldığı ve linkler gönderilene kadar kimsenin fark etmediği durum.
Önerilen savunma ucuz: sakladığınız her sohbet için, kaydedilen handle'ın boş olmadığını ve string biçiminde id olmadığını assert edin. Testte tek bir satır ve ölü linklerin bir sınıfı kimseye ulaşmaz.
Belirtilmeye değer bir uyarı: yazıdaki canlı örnekler, yazının yazarının işlettiği görünen RapidAPI üzerinde barındırılan üçüncü taraf bir Telegram veri API'si üzerinden üretilmiş ve yazı onu tanıtarak bitiyor. Bu, belgelediği yanıt biçimlerini değiştirmiyor ama çerçeveyi açıklıyor.
Neden önemli
Boş string'e karşı null ayrımı klasik bir entegrasyon tuzağıdır ve Telegram'ın buradaki sözleşmesi alışılmadık derecede sinsi: dolu bir kavram — kanalın handle'ı — iki biçimden biriyle ifade ediliyor ve geliştiricilerin naive olarak kod yazdığı biçim yalnızca biri. Telegram handle'larını sonradan linkleme için saklayan her ürünün, bültenlerden analitik araçlarına kadar, üç adımlı fallback'e ihtiyacı var; aksi halde hiçbir şey hata fırlatmayan durumlarda tam olarak ölü linkler gönderir. Başarısızlık tasarım gereği sessiz: adı değişen kanal kitlesi için çalışmaya devam ederken saklı link sessizce çürüyor. Çözüm birkaç satır — ama ancak ikinci biçimin varlığını biliyorsanız.
- #telegram
- #api
- #edge-cases
- #rest-api