mckaywrigley/chatbot-ui · error · Error
error.message
Error message
error.message
What it means
Selecting chats for a workspace returned an error. PostgREST queries normally return an empty array on success, so a thrown error here means a transport/API failure, bad column reference, or RLS misconfiguration rather than 'no chats found'.
Source
Thrown at db/chats.ts:22
export const getChatById = async (chatId: string) => {
const { data: chat } = await supabase
.from("chats")
.select("*")
.eq("id", chatId)
.maybeSingle()
return chat
}
export const getChatsByWorkspaceId = async (workspaceId: string) => {
const { data: chats, error } = await supabase
.from("chats")
.select("*")
.eq("workspace_id", workspaceId)
.order("created_at", { ascending: false })
if (!chats) {
throw new Error(error.message)
}
return chats
}
export const createChat = async (chat: TablesInsert<"chats">) => {
const { data: createdChat, error } = await supabase
.from("chats")
.insert([chat])
.select("*")
.single()
if (error) {
throw new Error(error.message)
}
return createdChat
}View on GitHub (pinned to 81328b61d2)
Solutions
- Verify the chats table still has workspace_id and created_at columns
- Confirm the Supabase URL and anon key are correct and the project is reachable
- Guard on `if (error)` instead of `!chats` so empty results aren't misreported
- Check Supabase dashboard logs for the failing request
Example fix
// before
if (!chats) {
throw new Error(error.message)
}
// after
if (error) {
throw new Error(error.message)
}
return chats Defensive patterns
Strategy: try-catch
Validate before calling
if (!workspaceId) throw new Error("workspaceId is required"); Type guard
const isChat = (c: unknown): c is Tables<"chats"> => typeof c === "object" && c !== null && "id" in c;
Try / catch
try { return await getChatsByWorkspaceId(workspaceId) } catch (e) { if (e instanceof Error && /relation|column/i.test(e.message)) console.error("Schema mismatch:", e.message); return [] } Prevention
- Treat empty result as [] not an error
- Keep generated Supabase types in sync after migrations
- Monitor Supabase status for outages
When it happens
Trigger: Calling getChatsByWorkspaceId with a workspace that doesn't matter (empty array is fine) — the error path fires on network failure, a renamed/dropped column in .select/.order, or an RLS policy that errors instead of filtering.
Common situations: Renaming created_at or workspace_id in a migration without updating this query, stale generated Supabase types after schema change, or network/DNS issues against the Supabase project URL.
Related errors
AI-assisted analysis of mckaywrigley/chatbot-ui@81328b61d2 (2026-08-27).
Data as JSON: /api/errors/98cf86e38557139a.
Report an issue: GitHub.