FlowiseAI/Flowise · error · Error

Error retrieving ${tableName}

Error message

Error retrieving ${tableName}

What it means

Thrown by PostgresSaver.getTuple() inside the checkpoint_id-present branch when the SELECT-by-checkpoint_id query fails. The underlying error is console.error-logged then re-thrown as an opaque generic message. dataSource.destroy() always runs in finally.

Source

Thrown at packages/components/nodes/memory/AgentMemory/PostgresAgentMemory/pgSaver.ts:107

                if (rows && rows.length > 0) {
                    return {
                        config,
                        checkpoint: (await this.serde.parse(rows[0].checkpoint.toString())) as Checkpoint,
                        metadata: (await this.serde.parse(rows[0].metadata.toString())) as CheckpointMetadata,
                        parentConfig: rows[0].parent_id
                            ? {
                                  configurable: {
                                      thread_id,
                                      checkpoint_id: rows[0].parent_id
                                  }
                              }
                            : undefined
                    }
                }
            } catch (error) {
                console.error(`Error retrieving ${tableName}`, error)
                throw new Error(`Error retrieving ${tableName}`)
            } finally {
                await dataSource.destroy()
            }
        } else {
            try {
                const queryRunner = dataSource.createQueryRunner()
                const keys = [thread_id]
                const sql = `SELECT thread_id, checkpoint_id, parent_id, checkpoint, metadata FROM ${tableName} WHERE thread_id = $1 ORDER BY checkpoint_id DESC LIMIT 1`

                const rows = await queryRunner.manager.query(sql, keys)
                await queryRunner.release()

                if (rows && rows.length > 0) {
                    return {
                        config: {
                            configurable: {
                                thread_id: rows[0].thread_id,
                                checkpoint_id: rows[0].checkpoint_id

View on GitHub (pinned to abe4a8601a)

Solutions

1. Read the console.error line above the throw for the real Postgres error code (e.g. 42P01 undefined-table, 42703 undefined-column) and act on it.
2. If the table is missing or has the wrong shape, drop/recreate it or run setup() against a fresh table name so CREATE TABLE applies.
3. Confirm the checkpoint_id and thread_id passed in config.configurable are strings and non-empty.
4. Stabilize the connection (pool sizing, SSL config, network) if the underlying error is a socket/timeout.
5. As a maintainer, rethrow with cause to preserve diagnosability.

Example fix

// before
} catch (error) {
    console.error(`Error retrieving ${tableName}`, error)
    throw new Error(`Error retrieving ${tableName}`)
}
// after
} catch (error) {
    throw new Error(`Error retrieving ${tableName}: ${(error as Error).message}`, { cause: error })
}

function buildGetTupleConfig(threadId: string, checkpointId?: string) {
  if (!threadId || typeof threadId !== 'string') throw new Error('thread_id must be a non-empty string')
  if (checkpointId !== undefined && (typeof checkpointId !== 'string' || !checkpointId)) {
    throw new Error('checkpoint_id must be a non-empty string when provided')
  }
  return { configurable: { thread_id: threadId, ...(checkpointId ? { checkpoint_id: checkpointId } : {}) } }
}

function isCheckpointTupleRetrieveError(e: unknown): boolean {
  return e instanceof Error && /^Error retrieving .+$/.test(e.message)
}

try {
  const tuple = await saver.getTuple(config)
} catch (e) {
  if (e instanceof Error && /Error retrieving/.test(e.message)) {
    // read server log for underlying SQLSTATE; verify table existence and schema
  }
  throw e
}

When it happens

Trigger: Calling getTuple with config.configurable.checkpoint_id set, while: the table does not exist (setup skipped or failed silently elsewhere), the connection dropped, the column does not match (schema drift after a Flowise upgrade), or a parameter binding/type mismatch occurs.

Common situations: Schema drift after upgrading Flowise where the checkpoints table shape changed but the table already existed (so CREATE TABLE IF NOT EXISTS did not migrate it). Network blips to managed Postgres. Wrong tableName between savers sharing a DB.

Related errors

• Error retrieving ${tableName}
• Error listing ${tableName}
• Error saving checkpoint
• Error creating ${this.tableName} table
• Error listing ${tableName}

AI-assisted analysis of FlowiseAI/Flowise@abe4a8601a (2026-08-12). Data as JSON: /api/errors/e4f7063110a94709. Report an issue: GitHub.