psycopg2.errors.DuplicateTable: relation "task_id_sequence" already exists #14003

Closed
opened 2026-02-21 19:15:01 -05:00 by yindo · 10 comments
Owner

Originally created by @omegazeng on GitHub (May 19, 2025).

Self Checks

  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue,否则会被关闭。谢谢!:)
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.4.0

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

install

helm repo add douban https://douban.github.io/charts/
helm repo update douban
helm upgrade --install dify douban/dify -f value.yaml -n dify --version 0.6.2

kubectl exec -it -n dify dify-api-64ccd4f5bf-gml5q -- bash
flask db upgrade

init db failed

flask db upgrade

log

INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO  [alembic.runtime.migration] Will assume transactional DDL.
INFO  [alembic.runtime.migration] Running upgrade  -> 64b051264f32, init
Traceback (most recent call last):
  File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1967, in _exec_single_context
    self.dialect.do_execute(
  File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/default.py", line 941, in do_execute
    cursor.execute(statement, parameters)
psycopg2.errors.DuplicateTable: relation "task_id_sequence" already exists


The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/app/api/.venv/bin/flask", line 10, in <module>
    sys.exit(main())
             ^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/flask/cli.py", line 1129, in main
    cli.main()
  File "/app/api/.venv/lib/python3.12/site-packages/click/core.py", line 1363, in main
    rv = self.invoke(ctx)
         ^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/click/core.py", line 1830, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/click/core.py", line 1830, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/click/core.py", line 1226, in invoke
    return ctx.invoke(self.callback, **ctx.params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/click/core.py", line 794, in invoke
    return callback(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/click/decorators.py", line 34, in new_func
    return f(get_current_context(), *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/flask/cli.py", line 400, in decorator
    return ctx.invoke(f, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/click/core.py", line 794, in invoke
    return callback(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/flask_migrate/cli.py", line 154, in upgrade
    _upgrade(directory, revision, sql, tag, x_arg)
  File "/app/api/.venv/lib/python3.12/site-packages/flask_migrate/__init__.py", line 111, in wrapped
    f(*args, **kwargs)
  File "/app/api/.venv/lib/python3.12/site-packages/flask_migrate/__init__.py", line 200, in upgrade
    command.upgrade(config, revision, sql=sql, tag=tag)
  File "/app/api/.venv/lib/python3.12/site-packages/alembic/command.py", line 408, in upgrade
    script.run_env()
  File "/app/api/.venv/lib/python3.12/site-packages/alembic/script/base.py", line 586, in run_env
    util.load_python_file(self.dir, "env.py")
  File "/app/api/.venv/lib/python3.12/site-packages/alembic/util/pyfiles.py", line 95, in load_python_file
    module = load_module_py(module_id, path)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/alembic/util/pyfiles.py", line 113, in load_module_py
    spec.loader.exec_module(module)  # type: ignore
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap_external>", line 999, in exec_module
  File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
  File "/app/api/migrations/env.py", line 109, in <module>
    run_migrations_online()
  File "/app/api/migrations/env.py", line 103, in run_migrations_online
    context.run_migrations()
  File "<string>", line 8, in run_migrations
  File "/app/api/.venv/lib/python3.12/site-packages/alembic/runtime/environment.py", line 946, in run_migrations
    self.get_context().run_migrations(**kw)
  File "/app/api/.venv/lib/python3.12/site-packages/alembic/runtime/migration.py", line 623, in run_migrations
    step.migration_fn(**kw)
  File "/app/api/migrations/versions/64b051264f32_init.py", line 137, in upgrade
    op.execute('CREATE SEQUENCE task_id_sequence;')
  File "<string>", line 8, in execute
  File "<string>", line 3, in execute
  File "/app/api/.venv/lib/python3.12/site-packages/alembic/operations/ops.py", line 2552, in execute
    return operations.invoke(op)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/alembic/operations/base.py", line 441, in invoke
    return fn(self, operation)
           ^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/alembic/operations/toimpl.py", line 223, in execute_sql
    operations.migration_context.impl.execute(
  File "/app/api/.venv/lib/python3.12/site-packages/alembic/ddl/impl.py", line 253, in execute
    self._exec(sql, execution_options)
  File "/app/api/.venv/lib/python3.12/site-packages/alembic/ddl/impl.py", line 246, in _exec
    return conn.execute(construct, params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1418, in execute
    return meth(
           ^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/sql/elements.py", line 515, in _execute_on_connection
    return connection._execute_clauseelement(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1640, in _execute_clauseelement
    ret = self._execute_context(
          ^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1846, in _execute_context
    return self._exec_single_context(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1986, in _exec_single_context
    self._handle_dbapi_exception(
  File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 2355, in _handle_dbapi_exception
    raise sqlalchemy_exception.with_traceback(exc_info[2]) from e
  File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1967, in _exec_single_context
    self.dialect.do_execute(
  File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/default.py", line 941, in do_execute
    cursor.execute(statement, parameters)
sqlalchemy.exc.ProgrammingError: (psycopg2.errors.DuplicateTable) relation "task_id_sequence" already exists

[SQL: CREATE SEQUENCE task_id_sequence;]
(Background on this error at: https://sqlalche.me/e/20/f405)

✔️ Expected Behavior

No response

Actual Behavior

No response

Originally created by @omegazeng on GitHub (May 19, 2025). ### Self Checks - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue,否则会被关闭。谢谢!:) - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.4.0 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce # install ```bash helm repo add douban https://douban.github.io/charts/ helm repo update douban helm upgrade --install dify douban/dify -f value.yaml -n dify --version 0.6.2 kubectl exec -it -n dify dify-api-64ccd4f5bf-gml5q -- bash flask db upgrade ``` # init db failed ```bash flask db upgrade ``` ## log ``` INFO [alembic.runtime.migration] Context impl PostgresqlImpl. INFO [alembic.runtime.migration] Will assume transactional DDL. INFO [alembic.runtime.migration] Running upgrade -> 64b051264f32, init Traceback (most recent call last): File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1967, in _exec_single_context self.dialect.do_execute( File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/default.py", line 941, in do_execute cursor.execute(statement, parameters) psycopg2.errors.DuplicateTable: relation "task_id_sequence" already exists The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/app/api/.venv/bin/flask", line 10, in <module> sys.exit(main()) ^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/flask/cli.py", line 1129, in main cli.main() File "/app/api/.venv/lib/python3.12/site-packages/click/core.py", line 1363, in main rv = self.invoke(ctx) ^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/click/core.py", line 1830, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/click/core.py", line 1830, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/click/core.py", line 1226, in invoke return ctx.invoke(self.callback, **ctx.params) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/click/core.py", line 794, in invoke return callback(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/click/decorators.py", line 34, in new_func return f(get_current_context(), *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/flask/cli.py", line 400, in decorator return ctx.invoke(f, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/click/core.py", line 794, in invoke return callback(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/flask_migrate/cli.py", line 154, in upgrade _upgrade(directory, revision, sql, tag, x_arg) File "/app/api/.venv/lib/python3.12/site-packages/flask_migrate/__init__.py", line 111, in wrapped f(*args, **kwargs) File "/app/api/.venv/lib/python3.12/site-packages/flask_migrate/__init__.py", line 200, in upgrade command.upgrade(config, revision, sql=sql, tag=tag) File "/app/api/.venv/lib/python3.12/site-packages/alembic/command.py", line 408, in upgrade script.run_env() File "/app/api/.venv/lib/python3.12/site-packages/alembic/script/base.py", line 586, in run_env util.load_python_file(self.dir, "env.py") File "/app/api/.venv/lib/python3.12/site-packages/alembic/util/pyfiles.py", line 95, in load_python_file module = load_module_py(module_id, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/alembic/util/pyfiles.py", line 113, in load_module_py spec.loader.exec_module(module) # type: ignore ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "<frozen importlib._bootstrap_external>", line 999, in exec_module File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed File "/app/api/migrations/env.py", line 109, in <module> run_migrations_online() File "/app/api/migrations/env.py", line 103, in run_migrations_online context.run_migrations() File "<string>", line 8, in run_migrations File "/app/api/.venv/lib/python3.12/site-packages/alembic/runtime/environment.py", line 946, in run_migrations self.get_context().run_migrations(**kw) File "/app/api/.venv/lib/python3.12/site-packages/alembic/runtime/migration.py", line 623, in run_migrations step.migration_fn(**kw) File "/app/api/migrations/versions/64b051264f32_init.py", line 137, in upgrade op.execute('CREATE SEQUENCE task_id_sequence;') File "<string>", line 8, in execute File "<string>", line 3, in execute File "/app/api/.venv/lib/python3.12/site-packages/alembic/operations/ops.py", line 2552, in execute return operations.invoke(op) ^^^^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/alembic/operations/base.py", line 441, in invoke return fn(self, operation) ^^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/alembic/operations/toimpl.py", line 223, in execute_sql operations.migration_context.impl.execute( File "/app/api/.venv/lib/python3.12/site-packages/alembic/ddl/impl.py", line 253, in execute self._exec(sql, execution_options) File "/app/api/.venv/lib/python3.12/site-packages/alembic/ddl/impl.py", line 246, in _exec return conn.execute(construct, params) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1418, in execute return meth( ^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/sql/elements.py", line 515, in _execute_on_connection return connection._execute_clauseelement( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1640, in _execute_clauseelement ret = self._execute_context( ^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1846, in _execute_context return self._exec_single_context( ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1986, in _exec_single_context self._handle_dbapi_exception( File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 2355, in _handle_dbapi_exception raise sqlalchemy_exception.with_traceback(exc_info[2]) from e File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1967, in _exec_single_context self.dialect.do_execute( File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/default.py", line 941, in do_execute cursor.execute(statement, parameters) sqlalchemy.exc.ProgrammingError: (psycopg2.errors.DuplicateTable) relation "task_id_sequence" already exists [SQL: CREATE SEQUENCE task_id_sequence;] (Background on this error at: https://sqlalche.me/e/20/f405) ``` ### ✔️ Expected Behavior _No response_ ### ❌ Actual Behavior _No response_
yindo added the 🤔 cant-reproduce label 2026-02-21 19:15:01 -05:00
yindo closed this issue 2026-02-21 19:15:01 -05:00
Author
Owner

@dosubot[bot] commented on GitHub (May 19, 2025):

Hello @omegazeng! I'm Dosu, a bot here to help you solve bugs, answer questions, and guide you as a contributor. I'll assist you while you wait for a human maintainer. How can I help you today?

The error you're encountering, psycopg2.errors.DuplicateTable: relation "task_id_sequence" already exists, indicates that the sequence task_id_sequence is already present in your database, and the migration script is attempting to create it again. This can happen if the migration was partially applied or if the database wasn't properly reset before running the migration.

To resolve this issue, you can manually check if the sequence exists and drop it before running the migration again. Here are the steps you can follow:

  1. Access the Database:

    • Connect to your PostgreSQL database using a tool like psql or any database client.
  2. Check for the Sequence:

    • Run the following SQL command to check if the sequence exists:
      \ds
      
    • Look for task_id_sequence in the list of sequences.
  3. Drop the Sequence:

    • If the sequence exists, drop it using the following command:
      DROP SEQUENCE IF EXISTS task_id_sequence;
      
  4. Re-run the Migration:

    • After dropping the sequence, try running the migration again with:
      flask db upgrade
      

This should resolve the DuplicateTable error by ensuring that the sequence is not present before the migration script attempts to create it again.

To continue talking to Dosu, mention @dosu.


Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

@dosubot[bot] commented on GitHub (May 19, 2025): <!-- Greeting --> Hello @omegazeng! I'm [Dosu](https://dosu.dev), a bot here to help you solve bugs, answer questions, and guide you as a contributor. I'll assist you while you wait for a human maintainer. How can I help you today? <!-- Answer --> The error you're encountering, `psycopg2.errors.DuplicateTable: relation "task_id_sequence" already exists`, indicates that the sequence `task_id_sequence` is already present in your database, and the migration script is attempting to create it again. This can happen if the migration was partially applied or if the database wasn't properly reset before running the migration. To resolve this issue, you can manually check if the sequence exists and drop it before running the migration again. Here are the steps you can follow: 1. **Access the Database:** - Connect to your PostgreSQL database using a tool like `psql` or any database client. 2. **Check for the Sequence:** - Run the following SQL command to check if the sequence exists: ```sql \ds ``` - Look for `task_id_sequence` in the list of sequences. 3. **Drop the Sequence:** - If the sequence exists, drop it using the following command: ```sql DROP SEQUENCE IF EXISTS task_id_sequence; ``` 4. **Re-run the Migration:** - After dropping the sequence, try running the migration again with: ```bash flask db upgrade ``` This should resolve the `DuplicateTable` error by ensuring that the sequence is not present before the migration script attempts to create it again. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.* --- <sup>Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/1854e71e-a9e4-466d-970c-542f34607b5f?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/1854e71e-a9e4-466d-970c-542f34607b5f?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/1854e71e-a9e4-466d-970c-542f34607b5f?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/1854e71e-a9e4-466d-970c-542f34607b5f?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/1854e71e-a9e4-466d-970c-542f34607b5f?feedback_type=hallucination) | [Bug Report](https://app.dosu.dev/response-feedback/1854e71e-a9e4-466d-970c-542f34607b5f?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/1854e71e-a9e4-466d-970c-542f34607b5f?feedback_type=other)</sup>
Author
Owner

@omegazeng commented on GitHub (May 19, 2025):

After dropping SEQUENCE & TABLE , flask db upgrade was successful.

DROP SEQUENCE IF EXISTS task_id_sequence;
DROP SEQUENCE IF EXISTS taskset_id_sequence;
drop TABLE celery_taskmeta;
drop TABLE celery_tasksetmeta;

Why does a new installation have duplicate SEQUENCE & TABLE.
Is this a bug?

@omegazeng commented on GitHub (May 19, 2025): After dropping SEQUENCE & TABLE , `flask db upgrade` was successful. ```sql DROP SEQUENCE IF EXISTS task_id_sequence; DROP SEQUENCE IF EXISTS taskset_id_sequence; drop TABLE celery_taskmeta; drop TABLE celery_tasksetmeta; ``` Why does a new installation have duplicate SEQUENCE & TABLE. Is this a bug?
Author
Owner

@dosubot[bot] commented on GitHub (May 19, 2025):

The issue of duplicate sequences and tables during a new installation can occur if the database wasn't completely reset before the installation process. This might happen if there are remnants from a previous installation or if the migration scripts are run multiple times without clearing the database state.

To prevent this, ensure that the database is fully cleaned before starting a new installation. This involves removing any existing sequences, tables, and other database objects that might conflict with the migration scripts. The steps to reset or clean the Dify database before a new installation include stopping Docker containers, deleting volumes, and clearing specific directories and database entries [1][2].

If you followed these steps and still encountered duplicates, it might indicate a bug in the installation or migration scripts. In such cases, it would be helpful to report this behavior to the maintainers for further investigation.

To continue talking to Dosu, mention @dosu.


Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

@dosubot[bot] commented on GitHub (May 19, 2025): <!-- Answer --> The issue of duplicate sequences and tables during a new installation can occur if the database wasn't completely reset before the installation process. This might happen if there are remnants from a previous installation or if the migration scripts are run multiple times without clearing the database state. To prevent this, ensure that the database is fully cleaned before starting a new installation. This involves removing any existing sequences, tables, and other database objects that might conflict with the migration scripts. The steps to reset or clean the Dify database before a new installation include stopping Docker containers, deleting volumes, and clearing specific directories and database entries <sup>[[1]](https://github.com/langgenius/dify/issues/14431)</sup><sup>[[2]](https://github.com/langgenius/dify/issues/19086)</sup>. If you followed these steps and still encountered duplicates, it might indicate a bug in the installation or migration scripts. In such cases, it would be helpful to report this behavior to the maintainers for further investigation. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.* --- <sup>Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/99f32605-c983-4d7c-b6ff-89fe8d1f8c94?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/99f32605-c983-4d7c-b6ff-89fe8d1f8c94?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/99f32605-c983-4d7c-b6ff-89fe8d1f8c94?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/99f32605-c983-4d7c-b6ff-89fe8d1f8c94?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/99f32605-c983-4d7c-b6ff-89fe8d1f8c94?feedback_type=hallucination) | [Bug Report](https://app.dosu.dev/response-feedback/99f32605-c983-4d7c-b6ff-89fe8d1f8c94?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/99f32605-c983-4d7c-b6ff-89fe8d1f8c94?feedback_type=other)</sup>
Author
Owner

@crazywoola commented on GitHub (May 19, 2025):

After dropping SEQUENCE & TABLE , flask db upgrade was successful.

DROP SEQUENCE IF EXISTS task_id_sequence;
DROP SEQUENCE IF EXISTS taskset_id_sequence;
drop TABLE celery_taskmeta;
drop TABLE celery_tasksetmeta;
Why does a new installation have duplicate SEQUENCE & TABLE. Is this a bug?

We rebuilt the images v1.4.0 maybe it's the cause of this.

@crazywoola commented on GitHub (May 19, 2025): > After dropping SEQUENCE & TABLE , `flask db upgrade` was successful. > > DROP SEQUENCE IF EXISTS task_id_sequence; > DROP SEQUENCE IF EXISTS taskset_id_sequence; > drop TABLE celery_taskmeta; > drop TABLE celery_tasksetmeta; > Why does a new installation have duplicate SEQUENCE & TABLE. Is this a bug? We rebuilt the images v1.4.0 maybe it's the cause of this.
Author
Owner

@wqlparallel commented on GitHub (Jun 3, 2025):

After dropping SEQUENCE & TABLE , flask db upgrade was successful.
DROP SEQUENCE IF EXISTS task_id_sequence;
DROP SEQUENCE IF EXISTS taskset_id_sequence;
drop TABLE celery_taskmeta;
drop TABLE celery_tasksetmeta;
Why does a new installation have duplicate SEQUENCE & TABLE. Is this a bug?

We rebuilt the images v1.4.0 maybe it's the cause of this.

I encountered this issue in version 1.4.1 as well. How can we avoid this problem?

@wqlparallel commented on GitHub (Jun 3, 2025): > > After dropping SEQUENCE & TABLE , `flask db upgrade` was successful. > > DROP SEQUENCE IF EXISTS task_id_sequence; > > DROP SEQUENCE IF EXISTS taskset_id_sequence; > > drop TABLE celery_taskmeta; > > drop TABLE celery_tasksetmeta; > > Why does a new installation have duplicate SEQUENCE & TABLE. Is this a bug? > > We rebuilt the images v1.4.0 maybe it's the cause of this. I encountered this issue in version 1.4.1 as well. How can we avoid this problem?
Author
Owner

@knaou commented on GitHub (Jun 12, 2025):

I encountered this issue in version 1.4.2 as well.

@knaou commented on GitHub (Jun 12, 2025): I encountered this issue in version 1.4.2 as well.
Author
Owner

@wqlparallel commented on GitHub (Jun 21, 2025):

After dropping SEQUENCE & TABLE , flask db upgrade was successful.
DROP SEQUENCE IF EXISTS task_id_sequence;
DROP SEQUENCE IF EXISTS taskset_id_sequence;
drop TABLE celery_taskmeta;
drop TABLE celery_tasksetmeta;
Why does a new installation have duplicate SEQUENCE & TABLE. Is this a bug?

We rebuilt the images v1.4.0 maybe it's the cause of this.

Hi @crazywoola , this issue seems doesn't fixed completely. Could you reopen this issue for further investigation. If there's any additional information I can provide that would assist in troubleshooting the problem, I am more than willing to help.

@wqlparallel commented on GitHub (Jun 21, 2025): > > After dropping SEQUENCE & TABLE , `flask db upgrade` was successful. > > DROP SEQUENCE IF EXISTS task_id_sequence; > > DROP SEQUENCE IF EXISTS taskset_id_sequence; > > drop TABLE celery_taskmeta; > > drop TABLE celery_tasksetmeta; > > Why does a new installation have duplicate SEQUENCE & TABLE. Is this a bug? > > We rebuilt the images v1.4.0 maybe it's the cause of this. Hi @crazywoola , this issue seems doesn't fixed completely. Could you reopen this issue for further investigation. If there's any additional information I can provide that would assist in troubleshooting the problem, I am more than willing to help.
Author
Owner

@oussamach-ski commented on GitHub (Jul 14, 2025):

while migrate odoo sh 16 vers 18 i have this error
psycopg2.errors.DuplicateTable: relation "x_acquisition_bousten__message_main_attachment_id_index" already exists

@oussamach-ski commented on GitHub (Jul 14, 2025): while migrate odoo sh 16 vers 18 i have this error psycopg2.errors.DuplicateTable: relation "x_acquisition_bousten__message_main_attachment_id_index" already exists
Author
Owner

@joaomirandas commented on GitHub (Jul 17, 2025):

drop TABLE celery_tasksetmeta;

🎉 Woww Thanks!! That works for me! Running on version langgenius/dify-api:1.5.0 at k8s cluster on top of this helm chart

I think it should be reopened, deserves more investigation, looks like a bug in the order of actions when deploying.

@joaomirandas commented on GitHub (Jul 17, 2025): > drop TABLE celery_tasksetmeta; 🎉 Woww Thanks!! That works for me! Running on version `langgenius/dify-api:1.5.0` at k8s cluster on top of [this helm chart](https://github.com/BorisPolonsky/dify-helm) I think it should be reopened, deserves more investigation, looks like a bug in the order of actions when deploying.
Author
Owner

@kenwoodjw commented on GitHub (Jul 17, 2025):

I've found the method and reason to reproduce it:

  1. Start the Dify-worker first. and then run
flask db upgrade

Since Celery isn't configured with an environment variable, it defaults to creating tables in the DB.
https://github.com/langgenius/dify/blob/a4ef9009167ed7cf22b0b8bd3a903e8ba0a74567/api/configs/middleware/__init__.py#L211-L214
The solution is to add the variable to .env

CELERY_BACKEND=redis

or change code

class CeleryConfig(DatabaseConfig): 
     CELERY_BACKEND: str = Field( 
         description="Backend for Celery task results. Options: 'database', 'redis'.", 
-          default="database",
+          defualt="redis",
@kenwoodjw commented on GitHub (Jul 17, 2025): I've found the method and reason to reproduce it: 1. Start the Dify-worker first. and then run ``` flask db upgrade ``` Since Celery isn't configured with an environment variable, it defaults to creating tables in the DB. https://github.com/langgenius/dify/blob/a4ef9009167ed7cf22b0b8bd3a903e8ba0a74567/api/configs/middleware/__init__.py#L211-L214 The solution is to add the variable to `.env ` ``` CELERY_BACKEND=redis ``` or change code ```diff class CeleryConfig(DatabaseConfig): CELERY_BACKEND: str = Field( description="Backend for Celery task results. Options: 'database', 'redis'.", - default="database", + defualt="redis", ```
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#14003