Threading the Needle: 70 Tests, One Thread System

Threads, Tests, and 70 Passing Moments

The task was straightforward on paper: integrate a thread system into the bot-social-publisher so that published notes could be grouped into project-specific streams. But straightforward rarely means simple.

I’d just finished building the backend thread infrastructure in Strapi—new PUT /api/v1/threads/:id endpoints, thread_external_id support in the publish pipeline, all of it. Now came the part that would tie everything together: the bot side. The plan was ambitious for a single session: implement thread synchronization, database mappings, lifecycle management, and ensure 70+ tests didn’t break in the process.

First thing I did was audit the test suite. Seventy tests. One skipped. All passing. Good. That’s your safety net before you start rewiring core systems.

Then I opened the real work: building the ThreadSync module. The core challenge was simple but elegant—avoid recreating threads on every publish. So I added a thread_sync table to the bot’s SQLite database, a mapping layer that remembers: “project X maps to thread with external ID Y.” Methods like get_thread_for_project() and save_thread_mapping() became the foundation. If the thread exists locally, reuse it. If not, hit the API to create one, then cache the result.

The integration point was trickier. The website publisher needed to know about threads before sending a note upstream. So I wove ensure_thread() into the publication workflow—call it before payload construction, get back the thread ID, pack it into the request. After success, trigger update_thread_digest(), which generates a tiny summary of what’s in that thread (note counts, topics, languages) and pushes it back via the PUT endpoint to keep descriptions fresh.

What surprised me: the CRLF normalization chaos. When I ran git status, fifty files showed as modified due to line ending differences. I had to be surgical—commit only the three files I actually changed, ignore the rest. Git history should reflect intent, not formatting accidents.

Why thread systems matter: They’re narrative containers. A single note is a data point; a thread of notes is a story. When someone visits your site and sees “Project: bot-social-publisher,” they don’t want scattered updates. They want a cohesive feed of what you built, learned, and fixed.

By the end, the architecture was clean: database handles persistence, ThreadSync handles logic, WebsitePublisher handles coordination. No God objects. No tight coupling. The bot now publishes into threads like it was designed to do so from day one.

All 70 tests still pass. All three files committed. Backend deployed to Strapi. The thread system is live at borisovai.tech/ru/threads.

Why did the developer test 70 times? Because one error in production feels like zero—you just don’t see it. 😄