We hunted a duplicate writer for a screen showing four Discord cards

Our live screen showed the same Discord conversation four times in a row, and our first read was that something was writing duplicates.

That read sent us the wrong way. We treated the screen as a rendering of one conversation and went hunting for whatever was emitting the same card more than once. We had decided what the symptom meant before we checked what the cards were, so every finding got bent to fit “one thing repeating.”

None of it fit. Nothing was being written twice.

Four cards, four sessions

Each card was a real, separate session. A watcher polls Discord every five minutes. When it sees something that needs attention, it spawns an agent session to handle it. Five minutes later it polls again and can spawn another. Four cards on screen meant four sessions, each with its own start time and its own transcript.

The screen rendered those sessions with almost nothing to tell them apart. A card carried a title, often the untitled default, and a status. It said nothing about where the session came from or when the last message landed. Some cards had no body at all, so a fresh session that had not produced output yet drew as a blank rectangle.

Looking at that screen, you would conclude the system was doing one thing wrong: repeating itself. In fact it was doing what it was built to do, on a timer, in parallel, and reporting on itself badly.

The tell was in the session records. Every session stores its own start time and origin. Sorted by origin instead of by title, the screen held two populations: sessions the watcher raised, and sessions we started ourselves. The screen had merged them into one undifferentiated list.

The fix went into the card

We left the watcher alone. Its five-minute cadence was correct. The change went into the card:

• Origin. Every card shows where the session came from.
• Split. Watcher-raised cards and the ones we opened ourselves render separately, so the timer’s output no longer buries the conversations we are actually in.
• Last-message time. Each card shows when its most recent message landed, so four cards read as four different moments.
• Never blank. A card with no body yet shows what it knows instead of an empty box.

We built it and checked it against the live screen. It ran there uncommitted, waiting on our review before it went in.

Why a title and a status hid it

With only a title and a status on screen, parallel work and broken work look identical. Both produce many similar rows. If the rows carry no provenance and no timing, the only explanation available for “many similar things” is “something is duplicating,” and that explanation feels like a diagnosis even though it is a guess.

The data was there the whole time. Origins and start times sat in the session records. The screen just did not surface them, so we reasoned from the screen and built a theory the records would have killed in a minute.

Now, before we chase a duplicate, we pull the raw records behind the rows and check whether they are one thing or several. If the ids differ and the timestamps sit on a regular grid, it is concurrency, and the bug is in how it is displayed.

What to check first

When a monitoring screen shows many similar rows, look at the ids, origins and start times behind them before assuming something is duplicating. Have your screens show where each item came from and when it last changed, so parallel work does not read as broken work.

dxdev LESSON · paste into your AI coding agent
LESSON: Many Similar Rows Are Not Evidence of Duplication
SOURCE: dxdev.com/blog/parallel-sessions-look-like-duplication
WHAT HAPPENED: A live screen showed what looked like the same conversation repeated several times. I assumed something was emitting duplicates and started looking for a double write. It was not. A watcher polls a chat channel every five minutes and spawns a separate agent session for anything that needs attention, so each card was a real, distinct session. The screen showed only a title and a status, so parallel work and a duplication bug were indistinguishable on it. The fix went into the card: show where each session came from, separate watcher-raised sessions from ones I opened myself, show the time of the last message, and never render a blank card.
THE RULE: Before chasing a duplicate, pull the raw records behind the rows and ask whether they are one thing or several. Distinct ids on a regular time grid mean concurrency, and the defect is in how it is displayed. Show provenance and timing on any list that summarises automated work.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any dashboard or list of automated jobs or sessions that shows title and status but not origin or timing.
  2. Any place where a spawned or scheduled unit of work can render as an empty or untitled entry.
  3. Any debugging step that assumes a symptom means "one thing repeating" without checking the ids behind it.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.