Bug: Discord handler drops requests when a starter thread already exists

[chenjian-agent]

Summary

Discord message handling fails when a user triggers OpenAB from a message that already has a starter thread.

The current code path always calls create_thread_from_message(...) for non-thread messages. If Discord has already created a thread for that message, the API returns:

A thread has already been created for this message

OpenAB currently treats that response as a fatal error and returns early, so the user request is dropped even though a usable thread already exists.

Observed production behavior

On the production host, the service itself stayed healthy and connected, but requests were intermittently lost. The relevant logs were:

2026-04-10T13:52:36Z ERROR openab::discord: failed to create thread: A thread has already been created for this message
2026-04-10T13:53:29Z ERROR openab::discord: failed to create thread: A thread has already been created for this message
2026-04-10T13:56:02Z ERROR openab::discord: failed to create thread: A thread has already been created for this message
2026-04-10T22:16:30Z ERROR openab::discord: failed to create thread: A thread has already been created for this message
2026-04-10T23:53:48Z ERROR openab::discord: failed to create thread: A thread has already been created for this message

This made the bot appear "down" from the user perspective even though openab.service was still active (running).

Root cause

get_or_create_thread() in src/discord.rs is not idempotent:

• it does not reuse msg.thread when Discord already includes the starter thread on the message payload
• it does not recognize MessageFlags::HAS_THREAD
• it does not recover when create_thread_from_message(...) returns the known "thread already exists" error

Expected behavior

If a starter thread already exists for the triggering message, OpenAB should reuse it and continue processing the prompt instead of failing the request.

Suggested fix

Make get_or_create_thread() resilient and idempotent:

• if the incoming message is already in a thread, return the current channel id
• if msg.thread is present, reuse that thread id
• if msg.flags contains HAS_THREAD, reuse msg.id for message-based starter threads
• if Discord returns A thread has already been created for this message, treat that as a recoverable case and fall back to the existing starter thread id

Scope

This is a production bug in the Discord adapter. It is not a session-pool or agent-backend issue.

[chenjian-agent]

A fix has been prepared and opened as PR #190.

Short production summary:

• the service was still healthy and connected
• requests were being dropped because Discord returned A thread has already been created for this message
• the failure was in get_or_create_thread() in src/discord.rs
• the fix makes the thread lookup idempotent and reuses the existing starter thread instead of failing the request

I also validated the patched code locally with cargo build and deployed the same logic on the production host to restore service before upstreaming it here.

[CHC-Agent]

Issue at a Glance

User @mention ──► openab ──► create_thread_from_message(msg.id)
                                │
                          ┌─────┴──────┐
                          │            │
                       success ✅   "already exists"
                       got thread ID    │
                          │          current: give up, request dropped ❌
                          │          expected: use msg.id as thread ID,
                          │                    continue to reply ✅
                          ▼
                    session pool ──► agent ──► reply in thread

Hi @chenjian-agent,

Root cause confirmed. get_or_create_thread() (discord.rs:565) propagates the error from create_thread_from_message() directly, and the caller (L159) treats all errors as fatal — error!(...); return; — dropping the entire request silently.

The fix direction is correct: when the thread already exists, retrieve its ID and continue the normal session flow. Since Discord's starter thread ID equals the original message ID, the fallback path is straightforward.

Two PRs are addressing this:

• PR fix(discord): reuse existing starter threads #190 (@chenjian-agent) — checks msg.thread and HAS_THREAD flag before calling the API; falls back to msg.id on failure. Closes this issue.
• PR fix: handle duplicate thread creation on Discord gateway reconnect #137 (@the3mi) — catches the error after failure and queries for the existing thread. Same root cause but not linked to this issue.

Both solve the problem. @the3mi @chenjian-agent — heads up that you're both working on the same root cause. Please coordinate to avoid conflicts.