← All posts
behind the scenes
How we hunt bugs in disdroc
The passes behind 1.11 followed messages, permissions and calls through the moments where state changes.
nadirisimOctober 9, 20263 min read
The awkward moment is the test
A message arriving in an open chat is the easy case. The useful test is what happens when you switch chats while a file is uploading, reconnect while somebody edits a message, or leave a call while the microphone permission window is still open. The bug-hunt passes behind 1.11 spent time on those moments.
I do not want to describe a list of fixes as proof that disdroc is finished. It is more useful to explain the kinds of mistakes we found and the checks that keep them from quietly coming back. The 1.11 post covers the features; this is about the less visible work.
Messages that disappear without being deleted
History could skip messages when several had the same timestamp. That is easy to miss in a quiet conversation and easy to hit during a burst. Paging now distinguishes messages with the same time, so going to the next page does not jump over the rest of the burst.
Another case involved loading history while new events arrived. A late history response could replace newer state, losing a live message, an edit or a deletion from the view. The checks deliberately delay that response, send changes while it is waiting, and then let it finish. The final view has to retain those changes.
Replies, uploads and voice notes also need to belong to the chat where they started. Switching conversations during an upload should not put that file in the new message box. A failed send should retain what you need to retry, rather than emptying your draft as if it had succeeded.
Unread state after a reconnect
Unread badges can become stale when the connection drops. A reconnect that only adds new rows can also leave old edits and deletions on screen. The revised path refreshes unread state and the visible message window while retaining the reading position and composer where appropriate.
The unread-DM checks exercise read markers, stale snapshots and reconnects. A badge is small, but a stuck one teaches you to stop trusting the whole list. Refreshing it must not mark a conversation read merely because some background request finished.
Permissions while the app is open
Checking access when you open a channel is not enough. Someone can remove a role or make a channel private while the connection remains open. The security passes tested current permissions during live delivery, as well as what happens after kicks, bans and logout.
The rule has to apply to the next message and to related surfaces such as threads and unread counts. A screen disappearing is insufficient if its updates still arrive in the background. These checks look at delivery as well as what the interface displays.
Leaving means stopping
Calls had their own timing problems. A late microphone or camera request could finish after you left. Push-to-talk could remain active if the app missed the key release. Screen-share audio could interfere with the microphone path.
The call checks cover leaving, denied joins, late permissions and losing focus while push-to-talk is held. Leaving must stop capture, and a delayed result must not restart it. These are behaviours you should be able to rely on without knowing the reason behind the fix.
Look at the screen, too
The UI passes inspect desktop, portrait phone and landscape phone sizes, in English and Turkish, with light and dark themes. They check actions below the fold, clipped menus, readable labels and the space left for typing. A button that exists but cannot be reached is still a broken action.
There are limits to that evidence. Simulated media and phone-sized browser windows do not establish physical-phone performance, microphone quality or every native keyboard behaviour. Failed-send retry records are also held only for the current page session. Reloading is not a recovery guarantee. I want those limits stated alongside the fixes, and useful reproductions of what still goes wrong can go through Support.
Test, işlerin karıştığı anda başlıyor
Açık sohbete mesaj gelmesi kolay durum. Asıl yararlı test; dosya yüklenirken sohbet değiştirdiğinde, biri mesaj düzenlerken yeniden bağlandığında veya mikrofon izin penceresi açıkken aramadan çıktığında ne olduğu. 1.11'in arkasındaki hata arama çalışmaları bu anlara odaklandı.
Bir düzeltme listesini disdroc'un bittiğinin kanıtı gibi anlatmak istemiyorum. Bulduğumuz hata türlerini ve sessizce geri dönmelerini önleyen kontrolleri açıklamak daha yararlı. 1.11 yazısı özellikleri anlatıyor; bu yazı daha az görünen işlerle ilgili.
Silinmeden kaybolan mesajlar
Birkaç mesajın zaman damgası aynı olduğunda geçmiş bazılarını atlayabiliyordu. Sakin sohbette gözden kaçması, yoğun mesajlaşmada ortaya çıkması kolay. Sayfalama artık aynı zamana sahip mesajları birbirinden ayırıyor; sonraki sayfaya geçmek, o anda gelen diğer mesajların üzerinden atlamıyor.
Başka bir durum, geçmiş yüklenirken yeni olayların gelmesiydi. Geç dönen geçmiş yanıtı daha yeni durumun yerini alabiliyor; yeni mesajı, düzenlemeyi veya silme işlemini görünümden kaybedebiliyordu. Kontroller bu yanıtı bilerek geciktiriyor, beklerken değişiklik gönderiyor, sonra tamamlanmasına izin veriyor. Son görünümün bu değişiklikleri koruması gerekiyor.
Yanıtlar, yüklemeler ve sesli notlar da başladıkları sohbete ait kalmalı. Yükleme sırasında sohbet değiştirmek, dosyayı yeni mesaj kutusuna koymamalı. Başarısız gönderim, başarılı olmuş gibi taslağı boşaltmak yerine tekrar denemek için gerekenleri korumalı.
Yeniden bağlandıktan sonra okunmamışlar
Bağlantı koptuğunda okunmamış rozetleri güncelliğini yitirebiliyor. Yalnızca yeni satır ekleyen bir yeniden bağlanma işlemi, eski düzenlemeleri ve silinmiş mesajları da ekranda bırakabiliyor. Düzeltilen akış, uygun durumlarda okuma konumunu ve mesaj kutusunu koruyarak okunmamış durumunu ve görünen mesaj aralığını yeniliyor.
Okunmamış DM kontrolleri; okuma işaretlerini, eski durum yanıtlarını ve yeniden bağlanmayı sınadı. Rozet küçük ama takılı kalması bütün listeye güvenmeyi bırakmana yol açıyor. Arka plandaki bir istek tamamlandı diye sohbet okunmuş sayılmamalı.
Uygulama açıkken değişen izinler
Kanalı açarken erişimi kontrol etmek yetmiyor. Bağlantı açıkken birisi rolü kaldırabilir veya kanalı özel yapabilir. Güvenlik kontrolleri, canlı mesaj iletiminde mevcut izinlerin uygulanmasını ve atma, yasaklama, oturum kapatma sonrasını sınadı.
Kuralın sonraki mesaja, konulara ve okunmamış sayılarına da uygulanması gerekiyor. Güncellemeler arka planda gelmeye devam ediyorsa ekranın kapanması yeterli değil. Bu kontroller, arayüzün gösterdikleri kadar mesajların kime iletildiğine de bakıyor.
Çıkmak, durdurmak demek
Aramalarda da zamanlamadan kaynaklanan sorunlar vardı. Mikrofon veya kamera isteği, sen çıktıktan sonra tamamlanabiliyordu. Uygulama tuşun bırakılmasını kaçırdığında bas-konuş açık kalabiliyordu. Ekran paylaşımı sesi mikrofon akışını etkileyebiliyordu.
Arama kontrolleri; çıkmayı, reddedilen katılımları, geç gelen izinleri ve bas-konuş tuşu tutulurken odağın kaybolmasını kapsıyor. Çıkmak, yakalamayı durdurmalı; geciken sonuç tekrar başlatmamalı. Düzeltmenin sebebini bilmeden güvenebilmen gereken davranışlar bunlar.
Ekrana da bak
Arayüz kontrollerinde masaüstü, dikey telefon ve yatay telefon boyutları; İngilizce ve Türkçe, açık ve koyu temalar inceleniyor. Ekranın altında kalan işlemlere, kesilen menülere, okunabilir etiketlere ve yazmak için kalan alana bakılıyor. Var olan ama ulaşılamayan düğme hâlâ bozuk bir işlem demek.
Bu kanıtların sınırları var. Taklit edilen medya ve telefon boyutundaki tarayıcı pencereleri; gerçek telefon performansını, mikrofon kalitesini veya bütün yerel klavye davranışlarını göstermiyor. Başarısız gönderimlerin tekrar deneme kayıtları da yalnızca mevcut sayfa oturumunda tutuluyor. Sayfayı yenilemek bir kurtarma garantisi değil. Bu sınırların düzeltmelerin yanında yazmasını istiyorum. Devam eden sorunları nasıl tekrar oluşturabileceğimizi Destek üzerinden anlatabilirsin.