Migration Bug: DrizzleQueryError: Failed query: ALTER TABLE "agents" ALTER COLUMN "title" SET DATA TYPE varchar(255);

[Ar4ikov]

📦 Platform

Self hosting Docker

📦 Deploymenet mode

server db(lobe-chat-database image)

📌 Version

1.133.2

💻 Operating System

Other Linux

🌐 Browser

Safari

🐛 Bug Description

Hello! I've experienced a bug when updating to 1.133.2 version
DrizzleQueryError: Failed query: ALTER TABLE "agents" ALTER COLUMN "title" SET DATA TYPE varchar(255);

I'm building self image with some branding.ts changes with Docker from Dockerfile.database file.
Logs of Lobechat container:

🌐 DNS Server: [ '127.0.0.11' ]
lobe-chat  | -------------------------------------
lobe-chat  | [Database] Start to migration...
lobe-chat  | ❌ Database migrate failed. Please check your database is valid and DATABASE_URL is set correctly. The error detail is below:
lobe-chat  | DrizzleQueryError: Failed query: ALTER TABLE "agents" ALTER COLUMN "title" SET DATA TYPE varchar(255);
lobe-chat  | params: 
lobe-chat  |     at NodePgPreparedQuery.queryWithCache (/app/node_modules/drizzle-orm/pg-core/session.cjs:66:15)
lobe-chat  |     at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
lobe-chat  |     at async /app/node_modules/drizzle-orm/pg-core/dialect.cjs:66:13
lobe-chat  |     ... 3 lines matching cause stack trace ...
lobe-chat  |     at async runMigrations (/app/docker.cjs:17:3) {
lobe-chat  |   query: 'ALTER TABLE "agents" ALTER COLUMN "title" SET DATA TYPE varchar(255);',
lobe-chat  |   params: [],
lobe-chat  |   cause: error: value too long for type character varying(255)
lobe-chat  |       at /app/node_modules/.pnpm/[email protected]/node_modules/pg/lib/client.js:545:17
lobe-chat  |       at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
lobe-chat  |       at async /app/node_modules/drizzle-orm/node-postgres/session.cjs:148:20
lobe-chat  |       at async NodePgPreparedQuery.queryWithCache (/app/node_modules/drizzle-orm/pg-core/session.cjs:64:16)
lobe-chat  |       at async /app/node_modules/drizzle-orm/pg-core/dialect.cjs:66:13
lobe-chat  |       at async NodePgSession.transaction (/app/node_modules/drizzle-orm/node-postgres/session.cjs:220:22)
lobe-chat  |       at async PgDialect.migrate (/app/node_modules/drizzle-orm/pg-core/dialect.cjs:62:5)
lobe-chat  |       at async Object.migrate (/app/node_modules/drizzle-orm/node-postgres/migrator.cjs:27:3)
lobe-chat  |       at async runMigrations (/app/docker.cjs:17:3) {
lobe-chat  |     length: 99,
lobe-chat  |     severity: 'ERROR',
lobe-chat  |     code: '22001',
lobe-chat  |     detail: undefined,
lobe-chat  |     hint: undefined,
lobe-chat  |     position: undefined,
lobe-chat  |     internalPosition: undefined,
lobe-chat  |     internalQuery: undefined,
lobe-chat  |     where: undefined,
lobe-chat  |     schema: undefined,
lobe-chat  |     table: undefined,
lobe-chat  |     column: undefined,
lobe-chat  |     dataType: undefined,
lobe-chat  |     constraint: undefined,
lobe-chat  |     file: 'varchar.c',
lobe-chat  |     line: '638',
lobe-chat  |     routine: 'varchar'
lobe-chat  |   }
lobe-chat  | }
lobe-chat  | ❌ Error during DB migration:
lobe-chat  | Error: 🔴 Process exited with code 1
lobe-chat  |     at ChildProcess.<anonymous> (/app/startServer.js:109:39)
lobe-chat  |     at ChildProcess.emit (node:events:508:28)
lobe-chat  |     at maybeClose (node:internal/child_process:1101:16)
lobe-chat  |     at ChildProcess._handle.onexit (node:internal/child_process:305:5)

PostgreSQL database version: 16
PostgreSQL container logs:

lobe-postgres-16  | 2025-09-30 12:11:22.733 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
lobe-postgres-16  | 2025-09-30 12:11:22.733 UTC [1] LOG:  listening on IPv6 address "::", port 5432
lobe-postgres-16  | 2025-09-30 12:11:22.770 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
lobe-postgres-16  | 2025-09-30 12:11:22.794 UTC [29] LOG:  database system was shut down at 2025-09-30 12:11:22 UTC
lobe-postgres-16  | 2025-09-30 12:11:22.794 UTC [30] FATAL:  the database system is starting up
lobe-postgres-16  | 2025-09-30 12:11:22.794 UTC [31] FATAL:  the database system is starting up
lobe-postgres-16  | 2025-09-30 12:11:22.797 UTC [1] LOG:  database system is ready to accept connections
lobe-postgres-16  | 2025-09-30 12:11:29.141 UTC [45] ERROR:  value too long for type character varying(255)
lobe-postgres-16  | 2025-09-30 12:11:29.141 UTC [45] STATEMENT:  ALTER TABLE "agents" ALTER COLUMN "title" SET DATA TYPE varchar(255);

After several times I've got a solution for fixing those migrations:

UPDATE agents SET title = LEFT(title, 255) WHERE LENGTH(title) > 255;
UPDATE agents SET description = LEFT(description, 1000) WHERE LENGTH(description) > 1000;

But before I've run manually:

• 0032_improve_agents_field.sql (that was a problem one migration)
• 0033_add_table_index.sql
• 0034_fix_chat_group.sql
• 0035_add_virtual.sql

📷 Recurrence Steps

No response

🚦 Expected Behavior

No response

📝 Additional Information

No response

[lobehubbot]

👀 @Ar4ikov

Thank you for raising an issue. We will investigate into the matter and get back to you as soon as possible.
Please make sure you have given us as much context as possible.

[dosubot[bot]]

Hi @Ar4ikov! I'm Dosu and I’m helping the lobe-chat team.

The migration error happens because existing data in the agents.title column exceeds the new varchar(255) limit, so PostgreSQL blocks the schema change until all values fit the constraint. Your workaround—truncating values with UPDATE agents SET title = LEFT(title, 255) WHERE LENGTH(title) > 255;—is the recommended solution and matches both official migration scripts and community guidance for Lobe Chat. This approach is also used for other columns, like description, when their length limits change [source 1] [source 2].

Recent migration scripts have adjusted these truncation lengths (for example, truncating title to 200 and description to 300 before altering column types), so always check the latest migration files for the correct limits [source 3]. There’s currently no automated pre-check or tooling in the codebase to surface constraint violations before migrations—you need to manually check and clean up data before running the migration [source 4].

Best practice: always back up your database before truncating or migrating, and use SQL queries to count and review affected records before making changes. Once all values fit the new limits, the migration should complete without errors.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[arvinxx]

You are right. And we do the same thing in the improve agent field sql