SDK: getDialogue(id) returns undefined for a dialogue that was just created

[dialoguedb-bot]

Source

Daily user testing — 2026-06-17
Persona: Blessing Okonkwo — 20-year-old CS student, building a hackathon chatbot project

Finding

After creating a dialogue with db.createDialogue(), calling db.getDialogue(dialogueId) with the returned ID returns undefined.

Reproduction:

import { DialogueDB } from "dialogue-db"
const db = new DialogueDB({ apiKey: "skv1_..." })

const dialogue = await db.createDialogue({
  messages: [{ role: "user", content: "Hello" }],
  namespace: "student-001"
})
console.log("Created:", dialogue.id) // "01KVAPCXD5TAHFWGT7VABE4ZFQ"

const fetched = await db.getDialogue(dialogue.id)
console.log("Fetched:", fetched) // undefined

The dialogue IS retrievable via searchDialogues(), confirming it exists. loadMessages() on the original dialogue object also works. Only getDialogue() fails.

Tested with db.getDialogue("01KVAPCXD5TAHFWGT7VABE4ZFQ") (string ID) — returns undefined.
Tested with db.getDialogue({ dialogueId: "..." }) — throws "Invalid id: must be a string".

Impact

This breaks the basic read-after-write CRUD pattern. A developer who creates a dialogue, stores the ID, and later wants to retrieve it cannot do so. This is especially confusing for new users evaluating the product — it makes the database appear to lose data.

Combined with the listDialogues returning empty results, a developer cannot retrieve their own data except through the original dialogue object or via search. This severely undermines trust.

Suggested fix

Ensure getDialogue(id) correctly returns a dialogue that was recently created. If there's an eventual consistency delay, return a clear error or status indicator rather than undefined.

---

Automated from daily user testing

---

Dispatched from dialoguedb/hq#370

[dialoguedb-bot]

Understanding

The reported behavior is that db.getDialogue(dialogue.id) returns null for a dialogue just created with namespace: "student-001". The root cause is a namespace scoping gap in the DialogueDB class.

When createDialogue({ namespace: "student-001", ... }) succeeds, the API stores the dialogue under that namespace. But getDialogue(id) on DialogueDB (src/dialogue/class.dialogue-db.ts:48-61) constructs a GetDialogueInput with only { id } — no namespace — unless the caller explicitly passes options.namespace. The API layer (src/api/dialogue/dialogue.get.ts:18-20) then hits GET /api/v1/dialogue/{id} without ?namespace=student-001, and the backend returns 404, which src/methods/getDialogue.ts:20 catches and converts to null.

The same gap affects listDialogues() and deleteDialogue() — they all require the caller to explicitly pass namespace, even though they were created through the same DialogueDB instance.

Notably, the Dialogue class does handle this correctly: once instantiated, it propagates this.#namespace to every child operation (saveMessage, loadMessages, end, createThread, etc. — see src/dialogue/class.dialogue.ts:267-432). The problem is isolated to DialogueDB-level methods that take a raw ID.

Approach

Add an optional namespace to DialogueDB that gets applied as a default across all its methods:

1. src/settings/class.SettingsContainer.ts — Add namespace?: string to the Settings type.
2. src/dialogue/class.dialogue-db.ts — In every method that accepts namespace (getDialogue, listDialogues, deleteDialogue, getMemory, deleteMemory, listMemories, getOrCreateDialogue, and the search methods), fall back to this.#settings.get("namespace") when the caller doesn't provide one.
3. Tests — Add cases for: (a) new DialogueDB({ apiKey, namespace }) applies namespace to getDialogue(id) without explicit option, (b) explicit options.namespace overrides the default, (c) no default namespace preserves current behavior.

This is the minimal change. The Dialogue class already propagates correctly once instantiated, so no changes needed there.

Alternative considered

We could make getDialogue automatically try without namespace and then retry with common namespaces, but that adds latency and doesn't actually solve the problem. The user knows their namespace; the SDK just needs a convenient way to set it once.

Questions

1. Should createDialogue also inherit the default namespace? If new DialogueDB({ apiKey, namespace: "student-001" }) is set, should db.createDialogue({}) automatically create in that namespace? I'd lean yes for consistency, but it changes the default behavior for createDialogue callers who omit namespace today.
2. Is namespace truly required by the API for GET-by-ID, or is it just a performance hint? If the backend can resolve an ID globally (just slower), the fix might be simpler — but the 404 behavior suggests it's required.

Scope estimate

Small — ~3 files changed, ~30 lines of production code, ~50 lines of tests. The pattern already exists in Dialogue class internals; we're lifting it to the DialogueDB level.

Use @claude to discuss further, or comment /claude-start when ready.

[devkobby24]

/claude-start

[dialoguedb-bot]

⚠️ Hit a problem.

Run: 29491937398