Class SlackConversationStore

packages/bot-slack/src/conversation-store.ts:36–230

 * Slack lookup that already produces the answer.
 */
export class SlackConversationStore {
  private readonly client: WebClient;
  private readonly botUserId: string;
  /** Bot token used to download uploaded files from their `url_private`. */
  private readonly botToken: string;
  private readonly filesConfig: FileDeliveryConfig;
  /** Stable threadIds → conversation keys ("channelId::scope"). */
  private readonly participated = new Set<string>();

  constructor(args: {
    client: WebClient;
    botUserId: string;
    botToken: string;
    files?: FileDeliveryConfig;
  }) {
    this.client = args.client;
    this.botUserId = args.botUserId;
    this.botToken = args.botToken;
    this.filesConfig = args.files ?? {};
  }

  private keyOf(k: ConversationKey): string {
    return `${k.channelId}::${k.scope}`;
  }

  /**
   * A *fresh* AG-UI threadId per turn.
   *
   * We deliberately do NOT reuse a stable per-conversation threadId.
   * Slack is our durable history (every turn is rebuilt from it via
   * {@link fetchHistory}), so the LangGraph thread only needs to live for
   * the duration of one turn. Reusing a stable threadId across turns lets
   * the server-side thread accumulate the agent's *internal* messages
   * (tool calls/results that never round-trip through Slack); on the next
   * turn `@ag-ui/langgraph` regenerates state and the now-larger existing
   * thread no longer matches the incoming history, surfacing as a
   * "Message not found" failure. A unique thread per turn sidesteps that
   * entirely. Restart-recovery for interrupts still works because the
   * picker carries its turn's threadId in Slack message metadata (see
   * `recoverFromStaleClick`).
   */
  private newThreadId(k: ConversationKey): string {
    return `slack-${k.channelId}-${k.scope}-${randomUUID()}`;
  }

  /**
   * Does the bot own this thread? "Ownership" means the bot has at least
   * one prior reply in it (which is the natural definition since the bot
   * only ever replies when @-mentioned or in a thread it already owns).
   *
   * Cached in-process; the first call after a restart is one Slack API
   * round-trip, subsequent calls are O(1).
   */
  async has(key: ConversationKey): Promise<boolean> {
    if (this.participated.has(this.keyOf(key))) return true;
    // DM "scope" is a sentinel — no Slack thread to query. We treat the
    // listener-level DM gate as authoritative; DMs always go through.
    if (key.scope === DM_SCOPE) return false;