Three Bugs, One Silent Failure: Debugging the Missing Thread Descriptions

Debugging Threads: When Empty Descriptions Meet Dead Code

The task started simple enough: fix the thread publishing pipeline on the social media bot. Notes were being created, but the “threads”—curated collections of related articles grouped by project—weren’t showing up on the website with proper descriptions. The frontend displayed duplicated headlines, and the backend API received… nothing.

I dove into the codebase expecting a routing issue. What I found was worse: three interconnected bugs, each waiting for the others to fail in just the right way.

The first problem lived in thread_sync.py. When the system created a new thread via the backend API, it was sending a POST request that omitted the description_ru and description_en fields entirely. Imagine posting an empty book to a library and wondering why nobody reads it. The thread existed, but it was invisible—a shell with a title and nothing else.

The second bug was subtler. The update_thread_digest method couldn’t see the current note being published. It only knew about notes that had already been saved to the database. For the first note in a thread, this meant the digest stayed empty until a second note arrived. But the third bug prevented that second note from ever coming.

That third bug was my favorite kind of disaster: dead code. In main.py, there was an entire block (lines 489–512) designed to create threads when enough notes accumulated. It checked should_create_thread(), which required at least two notes. But existing_notes always contained exactly one item—the note being processed right now. The condition never triggered. The code was there, debugged, probably tested once, and then forgotten.

The fix required threading together three separate changes. First, I updated ensure_thread() to accept note metadata and include it in the initial thread creation, so descriptions weren’t empty from day one. Second, I modified update_thread_digest() to accept the current note’s info directly, rather than waiting for database saves. Third, I ripped out the dead code block entirely—it was redundant with the ThreadSync approach that was actually being used.

Here’s something interesting about image compression that came up during the same session: the bot was uploading full 1200×630px images (OG-banner dimensions) to stream previews. Those Unsplash images weighed 289KB each; Pillow-generated fallbacks were PNG files around 48KB. For a thread with dozens of notes, that’s hundreds of megabytes wasted. I resized Unsplash requests to 800×420px and converted Pillow output to JPEG format. Result: 61% size reduction on external images, 33% on generated ones. The bot learned to compress before uploading.

Once deployed, the system retroactively created threads for all 12 projects. The website refreshed, duplicates vanished, and every thread now displays its full description with a curated summary of recent articles.

The lesson here? Dead code is a silent killer. It sits in your repository looking legitimate, maybe even well-commented, but it silently fails to do anything while the real logic runs elsewhere. Code review catches it sometimes. Tests catch it sometimes. Sometimes you just have to read the whole flow, start to finish, and ask: “Does this actually execute?”

😄 How do you know God is a shitty programmer? He wrote the OS for an entire universe, but didn’t leave a single useful comment.