【ヘルプ】Dify 1.11.4 デプロイ後、workerがデータテーブルpoll_workflow_schedulesの欠落を報告し、PostgreSQL設定

:bullseye: 助けてほしいこと

1. Worker サービスデータテーブルの欠落エラー

worker-1  |                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\nworker-1  |   File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/orm/context.py", line 306, in orm_execute_statement\nworker-1  |     result = conn.execute(\nworker-1  |              ^^^^^^^^^^^^^\nworker-1  |   File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1419, in execute\nworker-1  |     return meth(\nworker-1  |            ^^^^^\nworker-1  |   File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/sql/elements.py", line 526, in _execute_on_connection\nworker-1  |     return connection._execute_clauseelement(\nworker-1  |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\nworker-1  |   File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1641, in _execute_clauseelement\nworker-1  |     ret = self._execute_context(\nworker-1  |           ^^^^^^^^^^^^^^^^^^^^^^\nworker-1  |   File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1846, in _execute_context\nworker-1  |     return self._exec_single_context(\nworker-1  |            ^^^^^^^^^^^^^^^^^^^^^^^^^^\nworker-1  |   File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1986, in _exec_single_context\nworker-1  |     self._handle_dbapi_exception(\nworker-1  |   File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 2355, in _handle_dbapi_exception\nworker-1  |     raise sqlalchemy_exception.with_traceback(exc_info[2]) from e\nworker-1  |   File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1967, in _exec_single_context\nworker-1  |     self.dialect.do_execute(\nworker-1  |   File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/default.py", line 951, in do_execute\nworker-1  |     cursor.execute(statement, parameters)\nworker-1  | sqlalchemy.exc.ProgrammingError: (psycopg2.errors.UndefinedTable) relation "workflow_schedule_plans" does not exist\nworker-1  | LINE 2: FROM workflow_schedule_plans JOIN app_triggers ON app_trigge...\nworker-1  |              ^\nworker-1  | \nworker-1  | [SQL: SELECT workflow_schedule_plans.id, workflow_schedule_plans.app_id, workflow_schedule_plans.node_id, workflow_schedule_plans.tenant_id, workflow_schedule_plans.cron_expression, workflow_schedule_plans.timezone, workflow_schedule_plans.next_run_at, workflow_schedule_plans.created_at, workflow_schedule_plans.updated_at \nworker-1  | FROM workflow_schedule_plans JOIN app_triggers ON app_triggers.app_id = workflow_schedule_plans.app_id AND app_triggers.node_id = workflow_schedule_plans.node_id AND app_triggers.trigger_type = %(trigger_type_1)s \nworker-1  | WHERE workflow_schedule_plans.next_run_at <= %(next_run_at_1)s AND workflow_schedule_plans.next_run_at IS NOT NULL AND app_triggers.status = %(status_1)s ORDER BY workflow_schedule_plans.next_run_at ASC \nworker-1  |  LIMIT %(param_1)s FOR UPDATE SKIP LOCKED]\nworker-1  | [parameters: {'trigger_type_1': 'trigger-schedule', 'next_run_at_1': datetime.datetime(2026, 2, 4, 14, 16, 56, 757456), 'status_1': 'enabled', 'param_1': 100}]\nworker-1  | (Background on this error at: https://sqlalche.me/e/20/f405)\n```

このエラーが繰り返し発生し、スケジュールされたタスク `poll_workflow_schedules` が正常に実行できません。

## 📋 プロジェクト詳細

* Dify バージョン:1.11.4
* デプロイ方法:Docker Compose ローカルデプロイ
* オペレーティングシステム:Linux (Centos系)
* PostgreSQL イメージ:18.1-alpine3.23

## 

##

@Dify_Forum_Helper、問題の所在を詳しく説明してください。ついでに、GitHubで類似のIssueがないか確認してください。

あなたのログとコミュニティで見られる同様のケースから判断すると、この問題の本質は次のとおりです。

コアデータベースにテーブル workflow_schedule_plans がないため、worker が定期タスク poll_workflow_schedules を実行する際に、SQLが直接「relation … does not exist」というエラーを報告しています。
つまり、worker自体が壊れているのではなく、データベース移行によってこのテーブル(および他の可能性のあるテーブル)が作成されなかったということです。
以下に、考えられる原因と推奨されるトラブルシューティング手順をまとめます。


一、最も可能性の高い原因

  1. データベース移行(マイグレーション)が完全に実行されていない

    • Dify のすべてのビジネステーブル(workflow_schedule_plans を含む)は、Alembic 移行スクリプトによって初回起動時に自動的に作成されます。
    • もし:
      • 初回起動時に API コンテナが PostgreSQL に接続できなかった場合、または
      • 途中で手動でデータベースをクリアしたり、データベースを変更したりした場合、または
      • 権限の問題 / バージョンの非互換性により移行が失敗した場合
        このテーブルは作成されませんが、worker は引き続きそれを参照しようとし、結果としてあなたが見たエラーが発生します。
  2. データベースタイプの設定が一致しない(特に DB_TYPE

    • Dify は 1.10.x 以降、環境変数を使用してデータベースタイプを区別しています。例えば:
      • PostgreSQL:DB_TYPE=postgres
      • MySQL:DB_TYPE=mysql
    • もし docker-compose / .env で:
      • DB_TYPE が設定されていない場合、または
      • 間違った値に設定されている場合(例えば、以前にユーザーが seekdb と誤って記述したケースなど)
        移行スクリプトが誤った方言/エンジンで処理され、その結果:
    • 移行がスキップされるか失敗します。
    • 一部のテーブル(workflow_schedule_plans を含む)が作成されません。
  3. 以前にデータベースを変更またはテーブルをクリアしたが、移行を再実行しなかった

    • 例えば:
      • 最初に PostgreSQL インスタンスを使用し、後で接続文字列を新しいデータベースに変更した場合、または
      • PostgreSQL でスキーマをクリアした場合
    • しかし、API コンテナが「初期化 + 移行」を完全に再実行しなかった場合、このときに「あるテーブルは存在するが、別のテーブルは存在しない」という状況が発生します。

二、まずこれらの項目を自己確認してください

以下の操作はすべて「読み取り専用チェック」であり、データを破壊することはありません。

  1. PostgreSQL にこのテーブルが実際に存在しないことを確認する

    PostgreSQL コンテナまたはクライアントで以下を実行します。

    \dt workflow_schedule_plans
    

    または:

    SELECT *
    FROM information_schema.tables
    WHERE table_name = 'workflow_schedule_plans';
    

    ここで空であれば、移行が適切に実行されなかったことがほぼ確認できます。

  2. Dify のデータベース設定を確認する

    デプロイディレクトリ内の環境設定(通常は docker-compose.yml と同じディレクトリにある .env、または compose の environment: に直接記述されているもの)を見つけ、以下の項目に注目してください。

    DB_TYPE=postgres
    DB_USERNAME=...
    DB_PASSWORD=...
    DB_HOST=...
    DB_PORT=5432
    DB_DATABASE=...
    

    以下を確認してください。

    • DB_TYPE が存在し、postgres であること。
    • これらの値が、あなたの PostgreSQL インスタンスで実際に使用されているものと一致していること。
    • スペルミスや余分なスペースがないこと。
  3. API コンテナの起動ログに移行失敗の痕跡がないか確認する

    ホストマシンで以下を実行します。

    docker compose logs api | grep -i -E \"migrat|alembic|flask db\"
    

    もし以下のようなものが見つかった場合:

    • 「failed to run migrations」
    • またはトレースバックを含む Python 例外
      それは移行の問題であることをさらに確認できます。

三、比較的確実な修復手順(順序通りに実行することをお勧めします)

注意:以下のステップ2の flask db upgrade は「べき等」です。つまり、既に存在するテーブルは削除されず、作成されていないテーブルを補完するか、構造をアップグレードするだけであり、通常は安全です。

  1. まず設定が正しいことを確認し、その後再起動する

    .env または docker-compose.yml 内の API および worker で共有される環境変数を変更し、以下を確実に設定します。

    DB_TYPE=postgres
    

    その後、デプロイディレクトリで以下を実行します。

    docker compose down
    docker compose up -d
    

    すべてのサービスが安定して起動するのを待ってから、次のステップに進みます。

  2. 手動でデータベース移行を実行する

    API コンテナに入ります(コンテナ名は実際のものに合わせてください。通常 dify-api-1 などです)。

    docker exec -it <あなたの-api-コンテナ名> /bin/bash
    

    コンテナ内で以下を実行します。

    flask db upgrade
    

    通常、一連の「Running upgrade」のような出力が表示されます。途中でエラーが発生した場合は、そのエラーログ全体を貼り付けてください。これにより、さらに判断しやすくなります。

    移行が完了した後、コンテナ内から直接 PostgreSQL に接続するか(psql がインストールされている場合)、またはホストマシンでクライアントを使用して再度確認できます。

    SELECT *
    FROM information_schema.tables
    WHERE table_name = 'workflow_schedule_plans';
    

    この時点でテーブルが存在すれば、移行によって補完されたことになります。

  3. worker を再起動し、同じエラーがまだ発生するかどうかを確認する

    docker compose restart worker
    

    その後、worker のログにまだ以下が表示されるかどうかを確認します。

    relation "workflow_schedule_plans" does not exist
    

    表示されなくなれば、問題は解決です。まだ表示される場合は、別のテーブルの「does not exist」に変わっていないかを確認してください。その場合、さらに多くのテーブルが作成されていないことを意味し、同様に flask db upgrade で一度に補完されます。


四、上記操作後も問題が解決しない場合、以下の情報を提供してください

上記の手順を実行しても問題が解決しない場合は、このスレッドに以下の情報を追加してください。より具体的に問題を特定するのに役立ちます。

  1. 現在の docker-compose.yml または .env 内のデータベースに関する設定(パスワードは匿名化しても構いません):

    • DB_TYPE
    • DB_USERNAME
    • DB_HOST
    • DB_PORT
    • DB_DATABASE
  2. flask db upgrade の完全な出力(特にエラーのスタックトレースがあるかどうか)。

  3. PostgreSQL 内のすべての workflow_* 関連テーブルのリスト。例:

    SELECT table_name
    FROM information_schema.tables
    WHERE table_name LIKE 'workflow%';
    

五、GitHub / コミュニティでの状況との比較

GitHub やフォーラムでは、「特定のテーブルが存在しない → worker の定期タスクでエラー」というケースがいくつか報告されており、一般的な結論は次のとおりです。

  • 根本原因:初回初期化時に移行が完全に実行されなかった、または DB_TYPE の設定が誤っていたため、一連のテーブル(workflow_schedule_plans を含む)が全く作成されなかった。
  • 解決策:DB_TYPE を修正し、手動で flask db upgrade を実行する。その後、worker の poll_workflow_schedules は正常に動作するようになります。

あなたの Dify のバージョンは 1.11.4 であり、定期ワークフロー関連のテーブル定義は既に含まれています。したがって、移行が成功すれば、このテーブルは必ず存在します。「バージョンが古すぎてこのテーブルがない」という状況は発生しません。


まず「三、修復手順」を実行してみてください。もし可能であれば、以下の2点について先にお答えください。

  1. 現在の .env / compose 内の DB_TYPE の値は何ですか?
  2. flask db upgrade は正常に実行されましたか、何かエラーはありましたか?

あなたの具体的な出力に基づいて、次のステップをどのように処理するかをさらにサポートできます。

@Dify_Forum_Helper
$ flask db upgrade
WARNING: データベース「dify」には実際の照合バージョンがありませんが、バージョンが記録されました。
INFO [alembic.runtime.migration] コンテキスト実装 PostgresqlImpl.
INFO [alembic.runtime.migration] トランザクションDDLを仮定します。
INFO [alembic.runtime.migration] アップグレード 2adcbe1f5dfb → 4474872b0ee6 を実行中、workflow_draft_varaiblesnode_execution_id カラムを追加し、workflow_node_executions にインデックスを追加します。
Traceback (最新の呼び出しが最後):
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 951, in do_execute
cursor.execute(statement, parameters)
psycopg2.errors.DuplicateTable: リレーション “workflow_node_executions_tenant_id_idx” は既に存在します

上記の例外は、以下の例外の直接の原因でした:

Traceback (最新の呼び出しが最後):
File “/app/api/.venv/bin/flask”, line 10, in
sys.exit(main())
^^^^^^^^
File “/app/api/.venv/lib/python3.12/site-packages/flask/cli.py”, line 1131, in main
cli.main()
File “/app/api/.venv/lib/python3.12/site-packages/click/core.py”, line 1406, in main
rv = self.invoke(ctx)
^^^^^^^^^^^^^^^^
File “/app/api/.venv/lib/python3.12/site-packages/click/core.py”, line 1873, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/app/api/.venv/lib/python3.12/site-packages/click/core.py”, line 1873, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/app/api/.venv/lib/python3.12/site-packages/click/core.py”, line 1269, in invoke
return ctx.invoke(self.callback, **ctx.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/app/api/.venv/lib/python3.12/site-packages/click/core.py”, line 824, 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 824, 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 483, in upgrade
script.run_env()
File “/app/api/.venv/lib/python3.12/site-packages/alembic/script/base.py”, line 545, 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 116, 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 136, in load_module_py
spec.loader.exec_module(module) # type: ignore
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “<frozen importlib._bootstrap>”, line 999, in exec_module
File “<frozen importlib._bootstrap>”, line 488, in _call_with_frames_removed
File “/app/api/migrations/env.py”, line 110, in
run_migrations_online()
File “/app/api/migrations/env.py”, line 104, in run_migrations_online
context.run_migrations()
File “”, 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 627, in run_migrations
step.migration_fn(**kw)
File “/app/api/migrations/versions/2025_06_06_1424-4474872b0ee6_workflow_draft_varaibles_add_node_execution_id.py”, line 36, in upgrade
op.create_index(
File “”, line 8, in create_index
File “”, line 3, in create_index
File “/app/api/.venv/lib/python3.12/site-packages/alembic/operations/ops.py”, line 1013, in create_index
return operations.invoke(op)
^^^^^^^^^^^^^^^^^^^^^
File “/app/api/.venv/lib/python3.12/site-packages/alembic/operations/base.py”, line 454, in invoke
return fn(self, operation)
^^^^^^^^^^^^^^^^^^^
File “/app/api/.venv/lib/python3.12/site-packages/alembic/operations/toimpl.py”, line 112, in create_index
operations.impl.create_index(idx, **kw)
File “/app/api/.venv/lib/python3.12/site-packages/alembic/ddl/postgresql.py”, line 99, in create_index
self._exec(CreateIndex(index, **kw))
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 1419, in execute
return meth(
^^^^^
File “/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/sql/ddl.py”, line 187, in _execute_on_connection
return connection._execute_ddl(
^^^^^^^^^^^^^^^^^^^^^^^^
File “/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py”, line 1530, in _execute_ddl
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 951, in do_execute
cursor.execute(statement, parameters)
sqlalchemy.exc.ProgrammingError: (psycopg2.errors.DuplicateTable) リレーション “workflow_node_executions_tenant_id_idx” は既に存在します

[SQL: CREATE INDEX CONCURRENTLY workflow_node_executions_tenant_id_idx ON workflow_node_executions (tenant_id, workflow_id, node_id, created_at DESC)]
(このエラーの背景情報: Error Messages — SQLAlchemy 2.0 Documentation )

今回貼っていただいた flask db upgrade のログ情報は非常に重要で、現在の状態は以下の通りです。

  • Alembic はバージョン 2adcbe1f5dfb から 4474872b0ee6 へアップグレード中です。
  • このマイグレーションスクリプトでインデックス workflow_node_executions_tenant_id_idx を作成しようとしています。
  • しかし、データベースにはこのインデックスが既に存在するため、DuplicateTable エラーがスローされ、マイグレーション全体が中断されました。

したがって、現在の問題は次のようになります。

マイグレーション履歴とデータベースの実際の構造が「同期していない」状態です。

  • テーブル/インデックスに既に存在するものがいくつかありますが、Alembic はまだ作成されていないと認識しています。

これが、以前 workflow_schedule_plans テーブルが不足していた理由であり、手動でマイグレーションを実行した際に別のインデックスの重複で停止した理由でもあります。


1. 現在の推測のまとめ

  1. あなたのデータベースでは、既に部分的にマイグレーションが実行されています

    • 少なくとも workflow_node_executions_tenant_id_idx というインデックスは存在します。
    • しかし、workflow_schedule_plans テーブルはまだ存在しません(そうでなければ worker はエラーを出しません)。
  2. Alembic の「マイグレーション記録」は 2adcbe1f5dfb で停止しています。

    • ログから判断すると、現在 2adcbe1f5dfb → 4474872b0ee6 の実行を試みています。
    • これは、alembic_version テーブルに記録されている現在のバージョンがまだ 2adcbe1f5dfb であることを示しています。
    • しかし、実際のデータベースでは、「後続のいくつかのマイグレーションの一部操作」が既に実行されています(このインデックスのように)。

言い換えれば、
データベースの実際の構造 > Alembic が認識しているバージョン であり、そのため再実行時に「インデックスが既に存在する」という競合が発生しました。


2. 現在実行できるいくつかの調査手順

以下の操作はすべて、バックアップがあることを確認した上で行うことをお勧めします。特に alembic_version を直接操作したり、インデックスを削除したりする前には。

1. マイグレーションバージョンテーブルに現在記録されているバージョンを確認する

PostgreSQL で実行します。

SELECT * FROM alembic_version;

通常、1行あり、version_num が現在のマイグレーションバージョンです。
現在のログでは 2adcbe1f5dfb から 4474872b0ee6 へアップグレードしているため、理論的には version_num2adcbe1f5dfb であるはずです。

この値をメモしておいてください。後で必要になるかもしれません。

2. 関連オブジェクトの現状を確認する

PostgreSQL でそれぞれ確認してください。

-- 1) スケジュールプランテーブルがまだ存在しないか
SELECT *
FROM information_schema.tables
WHERE table_name = 'workflow_schedule_plans';

-- 2) 競合するインデックスが存在するか
SELECT indexname, indexdef
FROM pg_indexes
WHERE indexname = 'workflow_node_executions_tenant_id_idx';

-- 3) ベーステーブルが存在するか
SELECT *
FROM information_schema.tables
WHERE table_name = 'workflow_node_executions';

結果は高い確率で以下のようになるでしょう。

  • workflow_schedule_plans:見つからない;
  • workflow_node_executions:存在する;
  • workflow_node_executions_tenant_id_idx インデックス:存在する。

もしそうであれば、さらに以下のことが確認できます。
いくつかのマイグレーションステップは既に実行されています(インデックス作成など)が、マイグレーションシーケンス全体がAlembicによって正しく「記録」されていません。


3. 2つの一般的な修復アプローチ(A案を優先推奨)

操作を行う前に、データベースのバックアップ(少なくとも dify データベースのバックアップ)を必ず取得することを強くお勧めします。これにより、エラーが発生した場合にロールバックできます。

案A:重複するインデックスを削除し、マイグレーションを続行させる

考え方:重複しているのが「インデックス」であり「テーブル」ではないため、まずインデックスを削除し、Alembic に再作成させることで、マイグレーションが DuplicateTable で停止しなくなります。

  1. PostgreSQL で該当インデックスを削除します。

    DROP INDEX IF EXISTS workflow_node_executions_tenant_id_idx;
    

    インデックスを削除するだけではテーブルデータは削除されないため、リスクは比較的管理可能です。
    削除後、再度確認のために検索できます。

    SELECT indexname
    FROM pg_indexes
    WHERE tablename = 'workflow_node_executions';
    
  2. APIコンテナに戻り、再度マイグレーションを実行します。

    flask db upgrade
    

    このステップが正常に完了すると、以下のようになります。

    • 先ほど削除したインデックスを再構築します。
    • workflow_schedule_plans などのテーブル作成を含む、後続の未完了のすべてのマイグレーションを実行し続けます。
  3. マイグレーションが成功した後、主要なテーブルを再度確認します。

    SELECT *
    FROM information_schema.tables
    WHERE table_name = 'workflow_schedule_plans';
    

    この時点で存在していれば、worker を再起動し、元の poll_workflow_schedules エラーが解消されているかを確認できます。

案B:Alembic バージョンを手動で調整する(上級者向けでリスクが高い)

この方法は通常、「データベース構造は既に正しいが、Alembic のバージョン記録が遅れている」というシナリオで使用されます。以下の点を確認する必要があります。

  • 現在のデータベース内のテーブル/インデックス構造自体が完全かつ正しいこと。
  • 不足しているのは workflow_schedule_plans のようなテーブルのみであり、もし手動で作成/手動でマイグレーションを実行した場合は、それらが公式のマイグレーションスクリプトと一致していることを保証する必要があります。

おおよその手順(原理を理解するためのものであり、Alembic に詳しくない場合は直接これを行うことはお勧めしません)。

  1. データベース構造がより新しいマイグレーションバージョンと一致していることを確認した後、alembic_version テーブルの version_num を手動で更新し、重複するいくつかのマイグレーションをスキップします。
  2. その後、flask db upgrade を再度実行し、新しいベースラインから後続のマイグレーションを実行させます。

あなたの側では現在もテーブルが不足しているworkflow_schedule_plans)ため、直接案Bに進むのはあまり適切ではありません。そうでなければ、後続のマイグレーションでこのテーブルが既に存在すると仮定された場合、かえって多くの問題が発生しやすくなります。


4. 現在、以下の順序で操作することをお勧めします

  1. データベースのバックアップが完了していることを確認します(これは非常に重要です)。
  2. PostgreSQL で以下を実行します。
    • alembic_version の現在の値を確認します。
    • workflow_schedule_plans が実際に存在しないことを確認します。
    • workflow_node_executions_tenant_id_idx が実際に存在することを確認します。
  3. もし「テーブル不足 + 重複インデックス」の組み合わせである場合は、案Aに従います。
    • DROP INDEX IF EXISTS workflow_node_executions_tenant_id_idx;
    • APIコンテナで再度 flask db upgrade を実行します。
  4. マイグレーション完了後:
    • workflow_schedule_plans が作成されているか確認します。
    • worker を再起動し、poll_workflow_schedules がまだエラーを出しているか確認します。

5. 以下の情報について再度フィードバックをお願いします

他に隠れた問題がないことをさらに確認するため、次の返信で以下の情報を添付してください。

  1. PostgreSQL で実行した結果(実行結果を直接貼り付けてください)。

    SELECT * FROM alembic_version;
    
    SELECT *
    FROM information_schema.tables
    WHERE table_name = 'workflow_schedule_plans';
    
    SELECT indexname, indexdef
    FROM pg_indexes
    WHERE indexname = 'workflow_node_executions_tenant_id_idx';
    
  2. もし「DROP INDEX + 再度 flask db upgrade」を試された場合は、新しい flask db upgrade の完全な出力を貼り付けてください。

これらの結果に基づいて、他に手動で処理する必要があるマイグレーションの競合があるかどうかを確認するお手伝いをします。

@Dify_Forum_Helper
WARNING: database “dify” has no actual collation version, but a version was recorded
INFO \[alembic.runtime.migration\] Context impl PostgresqlImpl.
INFO \[alembic.runtime.migration\] Will assume transactional DDL.
INFO \[alembic.runtime.migration\] Running upgrade 2adcbe1f5dfb → 4474872b0ee6, workflow_draft_varaibles add node_execution_id column, add an index for workflow_node_executions.
INFO \[alembic.runtime.migration\] Running upgrade 4474872b0ee6 → 0ab65e1cc7fa, remove sequence_number from workflow_runs
INFO \[alembic.runtime.migration\] Running upgrade 0ab65e1cc7fa → 58eb7bdb93fe, add mcp server tool and app server
INFO \[alembic.runtime.migration\] Running upgrade 58eb7bdb93fe → 1c9ba48be8e4, add uuidv7 function in SQL
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 951, in do_execute
cursor.execute(statement, parameters)
psycopg2.errors.AmbiguousFunction: function name “uuidv7” is not unique
HINT: 引数リストを指定して関数を明確に選択してください。

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
sys.exit(main())
^^^^^^
File “/app/api/.venv/lib/python3.12/site-packages/flask/cli.py”, line 1131, in main
cli.main()
File “/app/api/.venv/lib/python3.12/site-packages/click/core.py”, line 1406, in main
rv = self.invoke(ctx)
^^^^^^^^^^^^^^^
File “/app/api/.venv/lib/python3.12/site-packages/click/core.py”, line 1873, in invoke
return \_process_result(sub_ctx.command.invoke(sub_ctx))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/app/api/.venv/lib/python3.12/site-packages/click/core.py”, line 1873, in invoke
return \_process_result(sub_ctx.command.invoke(sub_ctx))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/app/api/.venv/lib/python3.12/site-packages/click/core.py”, line 1269, in invoke
return ctx.invoke(self.callback, \*\*ctx.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/app/api/.venv/lib/python3.12/site-packages/click/core.py”, line 824, 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 824, 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 483, in upgrade
script.run_env()
File “/app/api/.venv/lib/python3.12/site-packages/alembic/script/base.py”, line 545, 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 116, 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 136, in load_module_py
spec.loader.exec_module(module) # type: ignore
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “”, line 999, in exec_module
File “”, line 488, in \_call_with_frames_removed
File “/app/api/migrations/env.py”, line 110, in
run_migrations_online()
File “/app/api/migrations/env.py”, line 104, in run_migrations_online
context.run_migrations()
File “”, 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 627, in run_migrations
step.migration_fn(\
\*kw)
File “/app/api/migrations/versions/2025_07_02_2332-1c9ba48be8e4_add_uuidv7_function_in_sql.py”, line 51, in upgrade
op.execute(sa.text(r"“”
File “”, line 8, in execute
File “”, line 3, in execute
File “/app/api/.venv/lib/python3.12/site-packages/alembic/operations/ops.py”, line 2591, in execute
return operations.invoke(op)
^^^^^^^^^^^^^^^^^^^^^
File “/app/api/.venv/lib/python3.12/site-packages/alembic/operations/base.py”, line 454, in invoke
return fn(self, operation)
^^^^^^^^^^^^^^^^^^^
File “/app/api/.venv/lib/python3.12/site-packages/alembic/operations/toimpl.py”, line 240, 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 1419, in execute
return meth(
^^^^^
File “/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/sql/elements.py”, line 526, in \_execute_on_connection
return connection.\_execute_clauseelement(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py”, line 1641, 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 951, in do_execute
cursor.execute(statement, parameters)
sqlalchemy.exc.ProgrammingError: (psycopg2.errors.AmbiguousFunction) function name “uuidv7” is not unique
HINT: 引数リストを指定して関数を明確に選択してください。

\[SQL:
/\* ミリ秒精度でuuidv7値を生成するメイン関数 \/
CREATE FUNCTION uuidv7() RETURNS uuid
AS
$$
– uuidv4の最初の48ビットを、1970-01-01 UTCからの現在のミリ秒数で置き換え
– 追加のビットを設定して「ver」フィールドを7に設定
SELECT encode(
set_bit(
set_bit(
overlay(uuid_send(gen_random_uuid()) placing
substring(int8send((extract(epoch from clock_timestamp()) \
1000)::bigint) from
3)
from 1 for 6),
52, 1),
53, 1), ‘hex’)::uuid;
$$ LANGUAGE SQL VOLATILE PARALLEL SAFE;

COMMENT ON FUNCTION uuidv7 IS
‘48ビットのタイムスタンプ(ミリ秒精度)と74ビットのランダム性を持つuuid-v7値を生成します’;

\]
(このエラーの背景についてはこちら: Error Messages — SQLAlchemy 2.0 Documentation )

今回のエラーは「テーブル不足」から典型的な「マイグレーションの重複実行」問題へと進化し、あなたはもう終わりに非常に近づいています。

現在の重要な情報は次のとおりです。

  • 以前の重複インデックスの問題はすでに処理されており、マイグレーションは続行できます。
  • 現在、マイグレーションバージョン 1c9ba48be8e4_add_uuidv7_function_in_sql.py で停止しています。
    • その中で CREATE FUNCTION uuidv7() RETURNS uuid ... を実行しようとしています。
    • しかし、データベースには すでに uuidv7 という名前の関数が存在する ため、PostgreSQL は次のように報告しています。
      \u003e function name “uuidv7” is not unique
      \u003e HINT: Specify the argument list to select the function unambiguously.

これは、データベースにすでに1つ(または複数)の uuidv7(...) 関数が存在するにもかかわらず、Alembic がまだ作成されていないと判断し、再度作成しようとしていることを意味します。


1. 全体的なアプローチ(以前の方法を継続)

以前の「重複インデックスを削除 → マイグレーションに再構築させる」というアプローチと同様に、ここでも次の方法を採用できます。

\u003e まず「競合するオブジェクト」(ここでは uuidv7 関数)をクリーンアップし、その後 Alembic にマイグレーションスクリプトを正常に実行させて再構築させます。

この関数は単なる「ユーティリティ関数」(uuidv7 を生成する)であるため、削除して公式スクリプトに従って再構築しても安全であり、ビジネスデータには影響しません。

前提として、現在のデータベースをバックアップすることを強くお勧めします。


2. 具体的な操作手順

以下の操作はすべて、Dify が使用している PostgreSQL データベース(例: dify)に接続して実行します。

1. 現在の uuidv7 関数の数を確認する

SELECT proname, oid, pg_get_function_identity_arguments(p.oid) AS args
FROM pg_proc p
JOIN pg_namespace n ON p.pronamespace = n.oid
WHERE n.nspname = 'public'
  AND proname = 'uuidv7';

おそらく1つまたは複数のレコードが表示されます。例:

  • uuidv7()(引数なし)
  • または、以前に手動で試したことがある場合は、いくつかのバリアント

マイグレーションスクリプトが作成しようとしているのは、引数なしの uuidv7() で、uuid を返します。

2. 既存の uuidv7() 関数を削除する

前のステップで引数なしの uuidv7() が1つ見つかった場合は、それを削除するだけで十分です。\n複数の同名バージョンがある場合は、すべて削除して、マイグレーションに一貫して再構築させることができます。

実行を推奨します。

DROP FUNCTION IF EXISTS uuidv7();

前のステップのクエリ結果に引数付きのバージョン(例: uuidv7(text) など)がまだある場合は、それらも一緒にクリアできます。

-- 特定の引数シグネチャのバージョンを実際に確認した場合は、必要に応じて行を追加してください。
-- DROP FUNCTION IF EXISTS uuidv7(text);
-- DROP FUNCTION IF EXISTS uuidv7(integer);

削除後、再度確認のためにクエリを実行できます。

SELECT proname, pg_get_function_identity_arguments(p.oid) AS args
FROM pg_proc p
JOIN pg_namespace n ON p.pronamespace = n.oid
WHERE n.nspname = 'public'
  AND proname = 'uuidv7';

理想的な状況では、ここに何も行が表示されません。

3. APIコンテナ内で再度マイグレーションを実行する

APIコンテナに戻ります。

docker exec -it <あなたの-api-容器名> /bin/bash

flask db upgrade

uuidv7 の競合がすでにクリーンアップされている場合、このステップはスムーズに実行されるはずです。

  • 1c9ba48be8e4 のステップで CREATE FUNCTION uuidv7() ... が再度実行されます。
  • その後、後続のマイグレーションが続行されます。

3. マイグレーションが実際に完了したか、およびテーブルが作成されたかを確認する

  1. データベースで alembic_version を確認します。

    SELECT * FROM alembic_version;
    

    ここには、ログで繰り返し表示される 2adcbe1f5dfb1c9ba48be8e4 などの途中バージョンではなく、比較的新しいバージョン番号 が表示されるはずです。

  2. 重要なテーブル workflow_schedule_plans がすでに存在するかどうかを再度確認します。

    SELECT *
    FROM information_schema.tables
    WHERE table_name = 'workflow_schedule_plans';
    

    ここで結果が表示されれば、このテーブルはマイグレーションスクリプトによって作成されたことになります。

  3. worker を再起動し、ログを監視します。

    docker compose restart worker
    

    その後、worker のログにまだ次のような表示があるかを確認します。

    relation "workflow_schedule_plans" does not exist
    
    • 表示されなくなった場合、poll_workflow_schedules 定期タスクは理論上正常に実行できるはずです。
    • 他のテーブルで「does not exist」が表示された場合、当初不足していたのはこのテーブルだけではなかったことを意味しますが、flask db upgrade が完全に成功していれば、その後テーブル不足が報告されるのは異常であり、具体的なテーブル名を再度確認する必要があります。

4. まだエラーが発生する場合は、以下の結果を返信で補足してください

上記の手順を完了した後、次のような場合:

  • flask db upgrade が依然として特定のマイグレーションでエラーを報告する場合、または
  • worker が依然として他のテーブル/関数でエラーを報告する場合、

スレッドに以下を再度投稿してください。

  1. 最新の flask db upgrade の完全な出力。
  2. 現在の alembic_version クエリ結果。
    SELECT * FROM alembic_version;
    
  3. 以下の2つのチェックの結果。
    SELECT *
    FROM information_schema.tables
    WHERE table_name = 'workflow_schedule_plans';
    
    SELECT proname, pg_get_function_identity_arguments(p.oid) AS args
    FROM pg_proc p
    JOIN pg_namespace n ON p.pronamespace = n.oid
    WHERE n.nspname = 'public'
      AND proname = 'uuidv7';
    

他にマイグレーションステップが一致していないか、または追加でクリーンアップが必要なオブジェクトがあるかどうかを再度確認するお手伝いをします。


要するに、あなたは問題を「テーブル不足によるworkerエラー」から「少数のマイグレーションスクリプトの重複実行衝突」へと絞り込みました。\nuuidv7 関数をクリアし、Alembic に再構築させることは、この種の衝突を解決する最も直接的で、ビジネスデータにとっても最も安全な方法です。

@Dify_Forum_Helper
以下の2つのSQLではデータが見つかりませんでした。
SELECT proname, p.oid::regprocedure, pg_get_function_identity_arguments(p.oid) AS args
FROM pg_proc p
JOIN pg_namespace n ON p.pronamespace = n.oid
WHERE n.nspname = ‘public’
AND proname = ‘uuidv7’;

SELECT proname, pg_get_function_identity_arguments(p.oid) AS args
FROM pg_proc p
JOIN pg_namespace n ON p.pronamespace = n.oid
WHERE n.nspname = ‘public’
AND proname = ‘uuidv7’;

しかし、publicの条件を削除すると、2行のデータが見つかります
「uuidv7」
「uuidv7」 「shift interval」

DROPを実行するとエラーが発生しました

DROP FUNCTION IF EXISTS uuidv7();

ERROR: cannot drop function uuidv7() because it is required by the database system

この情報は非常に重要で、問題の根本原因をほぼ特定できました。

  • public の下に uuidv7 が確かにありません。
  • しかし、ライブラリ全体で検索すると、uuidv7 / uuidv7(shift interval) が2つ見つかります。
  • そして、DROP FUNCTION uuidv7()cannot drop function uuidv7() because it is required by the database system というエラーを報告します。

これは次のことを裏付けています。
あなたは PostgreSQL 18 を使用しており、PostgreSQL 18 はシステム関数 uuidv7(...) のセットを内蔵しています。一方、Dify 1.11.4 のこのマイグレーションは、同じ名前の uuidv7() を再度作成しようとしており、その結果、システム関数名空間で衝突が発生し、このシステム関数は DROP できません。

この前提では、「関数を削除 → マイグレーションで再作成」という単純な方法は機能しません。


現在の状態の要約

  • あなたが現在直面しているのは、Dify 1.11.4 のマイグレーションスクリプトと PostgreSQL 18 に組み込まれた uuidv7() 関数との非互換性の問題です。
  • これはバージョン組み合わせにおける「新しい落とし穴」であり、あなたのローカル設定の問題ではありません。

このような衝突は、厳密には Dify 公式がマイグレーションスクリプトのレベルで適応させる必要があります(例えば、関数名を変更するか、既存の uuidv7() を検出した場合に作成をスキップするなど)。


現実的に可能な選択肢(いずれか1つを実行できます)

以下の解決策は、「安全で公式推奨」から「高度なスクリプト変更」の順に並んでいます。データベース運用にどれだけ慣れているかに応じて選択してください。

解決策 A: PostgreSQL 16 または 15 に変更して実行する(最も手間がかからず、現在のバージョンの期待に最も合致)

現在分かっていること:

  • PostgreSQL 18 から、公式に uuidv7() が組み込まれ、システムレベルで削除できません。
  • Dify 1.11.4 のマイグレーションの記述は「独自の uuidv7() 関数を作成する」というものです。

Dify 公式が PG18 に正式に対応するまで、最も確実な方法は、メジャーバージョンを1つ戻し、マイグレーションスクリプトが「システム uuidv7 がない環境」で正常に実行されるようにすることです。

  1. 現在の Dify および PG 18 コンテナを停止します(そして完全なバックアップを取ります)。

  2. PG 16 または 15 のイメージに切り替えます。例:

    services:
      postgres:
        image: postgres:16-alpine
        ...
    
  3. もし現在データベースに業務データがほとんどない場合(デプロイしたばかりでデバッグ段階の場合)、推奨されるのは:

    • 「クリーンな」新しいデータベースインスタンスを作成します。
    • DB_TYPE=postgres と接続文字列を設定します。
    • 再度 docker compose up -d を実行し、Dify がゼロから初期化され、自動的にマイグレーションが実行されるようにします。
    • その後、worker が workflow_schedule_plans の欠落を報告するかどうかを確認します。

もしすでにデータがある場合、PG 18 のデータを PG 16 に移行するには、かなり複雑になります(pg_dump / pg_restore が必要)。慣れていない場合は、慎重に評価することをお勧めします。

利点:

  • Dify のコードやマイグレーションスクリプトを手動で変更する必要がありません。
  • PostgreSQL のシステム関数と衝突することもありません。
  • 将来的に Dify のより高いバージョンにアップグレードする際にもより安全です。

解決策 B: この uuidv7 マイグレーションを一時的にスキップする(Alembic/SQL に詳しい人向け)

原理は次のとおりです。PG18 には uuidv7() が組み込まれているため、理論的には Dify の SQL 実装は不要であり、Alembic にこのマイグレーションがすでに実行されたと認識させ、後続のマイグレーションを続行させ、業務テーブル(workflow_schedule_plans を含む)を完全に構築することが重要です。

要点(Alembic に詳しくない場合は直接試すことは推奨しません):

  1. データベースで確認します。
    • workflow_schedule_plans およびその他の重要なテーブルが すでに存在するかどうか(まだ作成されていない場合は、以前のバージョンのマイグレーションがすべて通過したかどうかを確認する必要があります)。
  2. Alembic の alembic_version テーブルで、バージョン番号を現在の値から 1c9ba48be8e4 より高いバージョン に手動で変更します(つまり、このマイグレーションがすでに実行されたと仮定します)。
  3. 再度 flask db upgrade を実行し、新しいベースラインから実行させます。

リスクポイント:

  • 後続のマイグレーションが「Dify 独自の uuidv7 関数」の存在に依存している場合、新しい問題が発生する可能性があります(ただし、現在のコードを見る限り、この関数はあくまでユーティリティ関数であり、実際の業務テーブルは uuid 型自体を使用している可能性が高く、この SQL 関数に直接依存しているわけではありません)。

現在、システム関数名との衝突に直面しているため、この方法は理論的には可能ですが、次の点を非常に注意深く確認する必要があります。

  • テーブル構造が公式の期待と一致しているか。
  • どのマイグレーションが実際に DB レベルで「実行されたが、記録されていない」か。

Alembic と手動でのバージョン調整にあまり慣れていない場合、この方法は単独で試すことはあまり推奨されません。


解決策 C: ローカルでマイグレーションスクリプトを変更する(ソースコードを自分で管理してデプロイしている人向け)

ソースコード / 自作イメージでデプロイしており、公式の Docker イメージに完全に依存していない場合は、ローカルでそのマイグレーションスクリプトを次のように変更できます。

  • データベースに uuidv7() 関数がすでに存在する場合、作成を直接スキップする
  • または、Dify の関数名を dify_uuidv7() のように変更する。

ただし、これには次のことが伴います。

  1. api/migrations/versions/2025_07_02_2332-1c9ba48be8e4_add_uuidv7_function_in_sql.py の変更。
  2. 変更後のスクリプトがあなたの環境で実行可能であることを確認。
  3. 将来 Dify バージョンをアップグレードする際に、これが「ローカルでカスタマイズされた変更」であることを注意する。

これは「自己管理ブランチ」の範疇に属し、長期的な運用コストが高いため、通常は Python / Alembic / Postgres のすべてに詳しいユーザーにのみ推奨されます。


私の推奨優先順位

現在の調査プロセスと今回明らかになった PG 18 の動作を考慮すると、次の順序で検討することをお勧めします。

  1. 主要なデータベースを PostgreSQL 16 または 15 に変更し、マイグレーションを再初期化できるかどうかを優先的に評価してください

    • もし現在重要な業務データがない場合、これが最も簡単でクリーンな解決策です。
    • バージョンを変更して flask db upgrade を再度実行すれば、システム uuidv7() と衝突することはほとんどありません。
  2. もし PostgreSQL 18 を使用する必要がある場合:

    • この問題は本質的に「Dify 1.11.4 のマイグレーションスクリプトと PG 18 公式組み込みの uuidv7() との衝突」です。
    • 製品の観点から見ると、Dify 公式が将来のバージョンで修正する(例えば、マイグレーションロジックや関数名を変更するなど)のがより合理的です。
    • まず、フォーラム / GitHub で issue を立てて、次のことを説明できます。
      • Dify バージョン: 1.11.4
      • PostgreSQL バージョン: 18.1-alpine
      • マイグレーションが 1c9ba48be8e4_add_uuidv7_function_in_sql.py で停止していること
      • エラーが AmbiguousFunction: function name "uuidv7" is not unique であり、DROP FUNCTION uuidv7() が「required by the database system」と表示されること。

公式の修正または明確なガイダンスが出るまで、自分でマイグレーションスクリプトを変更したくない場合は、最も現実的なのは一時的に PG 16/15 に戻すことで、マイグレーションチェーン全体が「公式に検証済み」の組み合わせであることを保証します。


もし特定の解決策に進みたい場合(例えば、PG16 に変更する予定がある、または手動でこのマイグレーションをスキップすることを試したいなど)、どちらの道を進みたいか教えていただければ、その方向に沿って具体的な操作手順を直接実行可能なコマンドリストにさらに詳しくまとめることができます。

@Dify_Forum_Helper

新しいスクリプトを再ダウンロードしました。

Dify バージョン:1.12.1、

PostgreSQL バージョン:15-alphine

以前のすべてのコンテナ、ネットワーク、ボリュームを削除し、ローカルにマウントされたデータベースファイルも削除しました。

まず compose up postgresqlredis を実行し、コンテナの構築に成功しました。

compose up api を実行した際の記録は以下の通りです。すべてのデータテーブルの移行は成功しましたか?
api-1 | データベース移行を開始しています。

api-1 | INFO \[alembic.runtime.migration\] コンテキスト実装 PostgresqlImpl。

api-1 | INFO \[alembic.runtime.migration\] トランザクションDDLを仮定します。

api-1 | INFO \[alembic.runtime.migration\] アップグレードを実行中 → 64b051264f32, init

api-1 | INFO \[alembic.runtime.migration\] アップグレード 64b051264f32 → 9f4e3427ea84 を実行中, 作成者ロールを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 9f4e3427ea84 → a45f4dfde53b を実行中, おすすめアプリに言語を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード a45f4dfde53b → 614f77cecc48 を実行中, 最終アクティブ日時を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 614f77cecc48 → e32f6ccb87c6, e08af0a69ccefbb59fa80c778efee300bb780980 を実行中

api-1 | INFO \[alembic.runtime.migration\] アップグレード e32f6ccb87c6 → d3d503a3471c を実行中, 会話に is_deleted を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード d3d503a3471c → a5b56fb053ef を実行中, アプリ設定に speech_to_text を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード a5b56fb053ef → 2beac44e5f5f を実行中, アプリに is_universal を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 2beac44e5f5f → 7ce5a52e4eee を実行中, ツールプロバイダーを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 7ce5a52e4eee → 8d2d099ceb74 を実行中, QAモデルのサポートを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 8d2d099ceb74 → 16fa53d9faec を実行中, プロバイダーモデルのサポートを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 16fa53d9faec → e35ed59becda を実行中, クォータ制限フィールドタイプを変更

api-1 | INFO \[alembic.runtime.migration\] アップグレード e35ed59becda → bf0aec5ba2cf を実行中, プロバイダー順序を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード bf0aec5ba2cf → 5022897aaceb を実行中, 埋め込みにモデル名を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 5022897aaceb → 2c8af9671032 を実行中, QAドキュメント言語を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 2c8af9671032 → e8883b0148c9 を実行中, データセットモデル名を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード e8883b0148c9 → 853f9b9cd3b6 を実行中, メッセージ価格単位を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 853f9b9cd3b6 → 4bcffcd64aa4 を実行中, データセットモデルフィールドのNULL利用可能性を更新

api-1 | INFO \[allembic.runtime.migration\] アップグレード 4bcffcd64aa4 → 6dcb43972bdc を実行中, データセットリトリーバーリソースを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 6dcb43972bdc → 77e83833755c を実行中, アプリ設定リトリーバーリソースを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 77e83833755c → 6e2cfb077b04 を実行中, データセットコレクションバインディングを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 6e2cfb077b04 → ab23c11305d4 を実行中, アプリモデル設定にデータセットクエリ変数を追加。

api-1 | INFO \[alembic.runtime.migration\] アップグレード ab23c11305d4 → 2e9819ca5b28 を実行中, APIトークンにテナントIDを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 2e9819ca5b28 → b3a09c049e8e を実行中, 高度なプロンプトテンプレートを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード b3a09c049e8e → 968fff4c0ab9 を実行中, APIベースの拡張機能を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 968fff4c0ab9 → a9836e3baeee を実行中, アプリモデル設定に external_data_tools を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード a9836e3baeee → 8fe468ba0ca5 を実行中, gpt4v のサポートを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 8fe468ba0ca5 → fca025d3b60f を実行中, データセット検索モデルを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード fca025d3b60f → e1901f623fd0 を実行中, アノテーション返信を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード e1901f623fd0 → 46976cc39132 を実行中, アノテーション履歴スコアを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 46976cc39132 → f2a6fc85e260 を実行中, アノテーション履歴メッセージIDを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード f2a6fc85e260 → 714aafe25d39 を実行中, アノテーション履歴一致応答を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 714aafe25d39 → 246ba09cbbdb を実行中, アプリケーションアノテーション設定を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 246ba09cbbdb → 88072f0caa04 を実行中, テナントにカスタム設定を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 88072f0caa04 → 187385f442fc を実行中, プロバイダーモデル名の長さを変更

api-1 | INFO \[alembic.runtime.migration\] アップグレード 187385f442fc → 89c7899ca936 を実行中, 空のメッセージ

api-1 | INFO \[alembic.runtime.migration\] アップグレード 89c7899ca936 → 3ef9b2b6bee6 を実行中, アシスタントアプリを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 3ef9b2b6bee6 → ad472b61a054 を実行中, APIプロバイダーアイコンを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード ad472b61a054 → 8ec536f3c800 を実行中, APIプロバイダーの認証情報をリネーム

api-1 | INFO \[alembic.runtime.migration\] アップグレード 8ec536f3c800 → 00bacef91f18 を実行中, APIプロバイダーの説明をリネーム

api-1 | INFO \[alembic.runtime.migration\] アップグレード 00bacef91f18 → f25003750af4 を実行中, 作成/更新日時を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード f25003750af4 → c71211c8f604 を実行中, tool_invoke_model_log を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード c71211c8f604 → 114eed84c228 を実行中, モデル呼び出しからツールIDを削除

api-1 | INFO \[alembic.runtime.migration\] アップグレード 114eed84c228 → 4829e54d2fee を実行中, メッセージチェーンIDをNULL許容に変更

api-1 | INFO \[alembic.runtime.migration\] アップグレード 4829e54d2fee → 053da0c1d756 を実行中, APIツールプライバシーを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 053da0c1d756 → 4823da1d26cf を実行中, ツールファイルを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 4823da1d26cf → 9fafbd60eca1 を実行中, メッセージファイルの所属を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 9fafbd60eca1 → 8ae9bc661daa を実行中, ツール会話変数インデックスを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 8ae9bc661daa → 23db93619b9d を実行中, エージェントの思考にメッセージファイルを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 23db93619b9d → de95f5c77138 を実行中, serpapi_api_key の移行

api-1 | INFO \[alembic.runtime.migration\] アップグレード de95f5c77138 → b24be59fbb04 を実行中, 空のメッセージ

api-1 | INFO \[alembic.runtime.migration\] アップグレード b24be59fbb04 → dfb3b7f477da を実行中, ツールインデックスを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード dfb3b7f477da → 380c6aa5a70d を実行中, エージェントの思考にツールラベルを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 380c6aa5a70d → 16830a790f0f を実行中, 空のメッセージ

api-1 | INFO \[alembic.runtime.migration\] アップグレード 16830a790f0f → a8f9b3c45e4a を実行中, テナントIDデータベースインデックスを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード a8f9b3c45e4a → 17b5ab037c40 を実行中, キーワードテーブルストレージタイプを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード 17b5ab037c40 → a8d7385a7b66 を実行中, 埋め込みプロバイダー名を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード a8d7385a7b66 → b289e2408ee2 を実行中, ワークフローを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード b289e2408ee2 → cc04d0998d4d を実行中, モデル設定カラムをNULL許容に設定

api-1 | INFO \[alembic.runtime.migration\] アップグレード cc04d0998d4d → f9107f83abab を実行中, アプリに説明を追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード f9107f83abab → 42e85ed5564d を実行中, 会話カラムをNULL許容に設定

api-1 | INFO \[alembic.runtime.migration\] アップグレード 42e85ed5564d → b5429b71023c を実行中, メッセージカラムをNULL許容に設定

api-1 | INFO \[alembic.runtime.migration\] アップグレード b5429b71023c → 563cf8bf777b を実行中, 会話IDなしでツールファイルを有効化

api-1 | INFO \[alembic.runtime.migration\] アップグレード 563cf8bf777b → e2eacc9a1b63 を実行中, メッセージにステータスを追加

api-1 | INFO \[alembic.runtime.migration\] アップグレード e2eacc9a1b63 → c3311b089690 を実行中, ツールメタを追加api-1 | INFO [alembic.runtime.migration] アップグレード c3311b089690 → 3c7cac9521c6, タグとバインディングテーブルを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 3c7cac9521c6 → 47cc7df8c4f3, デフォルトのモデル名長を変更を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 47cc7df8c4f3 → 5fda94355fce, カスタム免責事項を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 5fda94355fce → 7bdef072e63a, ワークフローツールを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 7bdef072e63a → 3b18fea55204, ツールラベルバインディングを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 3b18fea55204 → 9e98fbaffb88, ワークフローツールバージョンを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 9e98fbaffb88 → 03f98355ba0e, ワークフローツールラベルとツールバインディングインデックスを追加を実行中
api-1 | INFO [allembic.runtime.migration] アップグレード 03f98355ba0e → 64a70a7aab8b, ワークフロー実行インデックスを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 64a70a7aab8b → 4e99a8df00ff, ロードバランシングを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 4e99a8df00ff → 7b45942e39bb, APIキー認証バインディングを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 7b45942e39bb → 4ff534e1eb11, サイトにワークフローを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 4ff534e1eb11 → b69ca54b9208, チャットボットのカラーテーマを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 4ff534e1eb11 → 04c602f5dc9b, AppModelConfigを更新し、TracingAppConfigテーブルを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 04c602f5dc9b → c031d46af369, アプリモデル設定トレース設定を削除し、トレースアプリ設定の名前を変更を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード c031d46af369 → 2a3aebbbf4bb, アプリトレースを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 2a3aebbbf4bb, b69ca54b9208 → 63f9175e515b, ブランチをマージを実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 63f9175e515b → b2602e131636, メッセージにworkflow_run_idインデックスを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード b2602e131636 → 7e6a8693e07a, dataset_permissionsテーブルを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 7e6a8693e07a → 161cadc1af8d, データセット権限テナントIDを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 161cadc1af8d → 408176b91ad3, 'add_max_active_requests’を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 408176b91ad3 → fecff1c3da27, 余分なトレースアプリ設定テーブルを削除し、idx_dataset_permissions_tenant_idを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード fecff1c3da27 → 6e957a32015b, 埋め込みキャッシュ作成日時インデックスを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 6e957a32015b → 8e5588e6412e, ワークフローモデルに環境変数を追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 8e5588e6412e → 53bf8af60645, モデルを更新を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 53bf8af60645 → eeb2e349e6ac, 最大モデル名長を増加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード eeb2e349e6ac → 1787fbae959a, ツールのoriginal_url長を更新を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 1787fbae959a → 63a83fcf12ba, 会話変数をサポートを実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 63a83fcf12ba → 8782057ff0dc, conversations.dialogue_countを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 8782057ff0dc → a6be81136580, アプリとサイトのアイコンタイプを実行中
api-1 | INFO [alembic.runtime.migration] アップグレード a6be81136580 → 2dbe42621d96, workflow__conversation_variablesをworkflow_conversation_variablesに名前変更を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 2dbe42621d96 → d0187d6a88dd, アプリ、モデル設定、サイトにcreated_byとupdated_byを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード d0187d6a88dd → 030f4915f36a, アプリとサイトにuse_icon_as_answer_iconフィールドを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 030f4915f36a → 675b5321501b, node_executionsにnode_execution_idを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 675b5321501b → d57ba9ebb251, メッセージにparent_message_idを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード d57ba9ebb251 → 6af6a521a53e, 検索リソースを更新を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 6af6a521a53e → 33f5fac87f29, 外部知識APIを実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 33f5fac87f29 → d8e744d88ed6, 誤ったサービスAPI履歴を修正を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード d8e744d88ed6 → bbadea11becb, tool_filesに名前とサイズを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード bbadea11becb → 0251a1c768cc, TiDB認証バインディングを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 0251a1c768cc → 43fa78bc3b7d, ホワイトリストを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 43fa78bc3b7d → d3f6769a94a3, upload_files.source_urlを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード d3f6769a94a3 → 93ad8c19c40b, 会話変数インデックス名を変更を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 93ad8c19c40b → f4d7ce70a7ca, upload_files.source_urlを更新を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード f4d7ce70a7ca → d07474999927, custom_disclaimerのタイプをTEXTに更新を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード d07474999927 → 09a8d1878d9b, ワークフローグラフ、機能、updated_atを更新を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 09a8d1878d9b → 01d6889832f7, メッセージにcreated_atインデックスを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 01d6889832f7 → cf8f4fc45278, WorkflowRunモデルにexceptions_countフィールドを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード cf8f4fc45278 → 11b07f66c737, 未使用のtool_providersを削除を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 11b07f66c737 → e1944c35e15e, ノード実行モデルにretry_indexフィールドを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード e1944c35e15e → d7999dfa4aae, workflow_node_executions.retry_indexが存在する場合、それを削除を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード d7999dfa4aae → e19037032219, 親子インデックスを実行中
api-1 | INFO [alembic.runtime.migration] アップグレード e19037032219 → 923752d42eb6, 自動無効化データセットログを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 923752d42eb6 → a91b476a53de, workflow_runs.total_tokensをbigintに変更を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード a91b476a53de → ddcc8bbef391, 組み込みツールプロバイダーの最大長を増加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード ddcc8bbef391 → 08ec4f75af5e, テナントプラグイン権限を追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 08ec4f75af5e → 4413929e1ec2, プロバイダー名カラムを拡張を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 4413929e1ec2 → 5511c782ee4c, プロバイダーカラムを拡張を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 5511c782ee4c → ee79d9b1c156, ワークフローにmarked_nameとmarked_commentを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード ee79d9b1c156 → f051706725cc, レート制限ログを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード f051706725cc → d20049ed0af6, メタデータ関数を追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード d20049ed0af6 → 6a9f914f656c, documentsegmentとchildchunkのインデックスを変更を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 6a9f914f656c → d28f2004b072, workflow_conversation_variables.conversation_idにインデックスを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード d28f2004b072 → 2adcbe1f5dfb, WorkflowDraftVariableモデルを追加を実行中
api-1 | INFO [alembic.runtime.migration] アップグレード 2adcbe1f5dfb → 4474872b0ee6, workflow_draft_variablesnode_execution_idカラムを追加し、workflow_node_executionsにインデックスを追加。を実行中api-1 | INFO [alembic.runtime.migration] アップグレード 4474872b0ee6 → 0ab65e1cc7fa を実行中, workflow_runsからsequence_numberを削除
api-1 | INFO [alembic.runtime.migration] アップグレード 0ab65e1cc7fa → 58eb7bdb93fe を実行中, mcpサーバーツールとアプリサーバーを追加
api-1 | INFO [alembic.runtime.migration] アップグレード 58eb7bdb93fe → 1c9ba48be8e4 を実行中, SQLにuuidv7関数を追加
api-1 | INFO [alembic.runtime.migration] アップグレード 1c9ba48be8e4 → 71f5020c6470 を実行中, ツールoauth
api-1 | INFO [alembic.runtime.migration] アップグレード 71f5020c6470 → 1a83934ad6d1 を実行中, モデルを更新
api-1 | INFO [alembic.runtime.migration] アップグレード 1a83934ad6d1 → 375fe79ead14 を実行中, oauth_refresh_token
api-1 | INFO [alembic.runtime.migration] アップグレード 375fe79ead14 → 8bcc02c9bd07 を実行中, tenant_plugin_autoupgradeテーブルを追加
api-1 | INFO [alembic.runtime.migration] アップグレード 8bcc02c9bd07 → 532b3f888abf を実行中, 手動データセットフィールドの更新
api-1 | INFO [alembic.runtime.migration] アップグレード 532b3f888abf → fa8b0fa6f407 を実行中, tool_mcp_providersにタイムアウトを追加
api-1 | INFO [alembic.runtime.migration] アップグレード fa8b0fa6f407 → e8446f481c1e を実行中, プロバイダーの複数資格情報サポートを追加
api-1 | INFO [alembic.runtime.migration] アップグレード e8446f481c1e → 0e154742a5fa を実行中, プロバイダーモデルの複数資格情報サポートを追加
api-1 | INFO [alembic.runtime.migration] アップグレード 0e154742a5fa → 8d289573e1da を実行中, 空のメッセージ
api-1 | INFO [alembic.runtime.migration] アップグレード 8d289573e1da → b95962a3885c を実行中, 雑務: ワークフローアプリログ実行IDインデックスを追加
api-1 | INFO [alembic.runtime.migration] アップグレード b95962a3885c → c20211f18133 を実行中, mcp_providerにヘッダーを追加
api-1 | INFO [alembic.runtime.migration] アップグレード c20211f18133 → cf7c38a32b2d を実行中, プロバイダーテーブルに資格情報ステータスを追加
api-1 | INFO [alembic.runtime.migration] アップグレード cf7c38a32b2d → 68519ad5cd18 を実行中, knowledge_pipelineの移行
api-1 | INFO [alembic.runtime.migration] アップグレード 68519ad5cd18 → d98acf217d43 を実行中, メッセージにapp_modeを追加
api-1 | INFO [alembic.runtime.migration] アップグレード d98acf217d43 → ae662b25d9bc を実行中, 組み込みテンプレートユーザーを削除
api-1 | INFO [alembic.runtime.migration] アップグレード ae662b25d9bc → 03f8dcbc611e を実行中, WorkflowPauseモデルを追加
api-1 | INFO [alembic.runtime.migration] アップグレード 03f8dcbc611e → 669ffd70119c を実行中, トリガーを導入
api-1 | INFO [alembic.runtime.migration] アップグレード 669ffd70119c → 09cfdda155d1 を実行中, mysqlへの適応
api-1 | INFO [alembic.runtime.migration] アップグレード 09cfdda155d1 → 7bb281b7a422 を実行中, workflow_pauses_reasonsテーブルを追加
api-1 | INFO [alembic.runtime.migration] アップグレード 7bb281b7a422 → d57accd375ae を実行中, マルチモーダルをサポート
api-1 | INFO [alembic.runtime.migration] アップグレード d57accd375ae → 03ea244985ce を実行中, type列にnot null default toolを追加
api-1 | INFO [alembic.runtime.migration] アップグレード 03ea244985ce → 7df29de0f6be を実行中, クレジットプールを追加
api-1 | INFO [alembic.runtime.migration] アップグレード 7df29de0f6be → 905527cc8fd3 を実行中, workflow_run_created_at_id_idxを追加
api-1 | INFO [alembic.runtime.migration] アップグレード 905527cc8fd3 → 3334862ee907 を実行中, 機能: メッセージにcreated_at IDインデックスを追加
api-1 | INFO [alembic.runtime.migration] アップグレード 3334862ee907 → 288345cd01d1 を実行中, ワークフローノード実行workflow_runインデックスを変更
api-1 | INFO [alembic.runtime.migration] アップグレード 288345cd01d1 → 9e6fa5cbcd80 を実行中, メッセージ注釈の質問をnot nullableにする
api-1 | INFO [alembic.runtime.migration] アップグレード 9e6fa5cbcd80 → f9f6d18a37f9 を実行中, テーブル探索バナーとトライアルを追加
api-1 | INFO [alembic.runtime.migration] アップグレード f9f6d18a37f9 → 9d77545f524e を実行中, workflow_archive_logsを作成
api-1 | INFO [alembic.runtime.migration] アップグレード 9d77545f524e → 788d3099ae3a を実行中, サマリーインデックス機能を追加
api-1 | データベースの移行に成功しました!
api-1 | [2026-02-07 08:43:33 +0000] [1] [INFO] gunicorn 23.0.0 を開始しています
api-1 | [2026-02-07 08:43:33 +0000] [1] [INFO] リッスン中: http://0.0.0.0:5001 (1)
api-1 | [2026-02-07 08:43:33 +0000] [1] [INFO] ワーカーを使用中: gevent
api-1 | [2026-02-07 08:43:33 +0000] [108] [INFO] pid: 108 でワーカーを起動中
api-1 | gRPCgeventでパッチ適用されました。
api-1 | psycopg2geventでパッチ適用されました。
api-1 | 2026-02-07 08:43:37.378 INFO [MainThread] [utils.py:151] - 注: NumExprは40コアを検出しましたが、"NUMEXPR_MAX_THREADS"が設定されていないため、安全な制限である16を適用します。
api-1 | 2026-02-07 08:43:37.379 INFO [MainThread] [utils.py:164] - NumExprはデフォルトで16スレッドを使用します。

はい、このログを見る限り、今回は「ゼロからの」完全な移行であり、正常に完了しています。以前のテーブル不足の問題は解決されたと考えることができます。

重要な兆候は2つあります。

  1. 移行パスが空のバージョンから最新バージョンまで実行されたこと
    ログの冒頭は次のとおりです。

    Running upgrade  -> 64b051264f32, init
    

    これは新しいデータベースであり、初期バージョンから実行が開始され、その後、あなたが貼り付けた数十行の Running upgrade ... -> ... が次のように続いています。

    INFO  [alembic.runtime.migration] Running upgrade 9d77545f524e -> 788d3099ae3a, add summary index feature
    Database migration successful!
    

    その中には、以前私たちが懸念していたいくつかのステップが含まれています。例えば:

    • b289e2408ee2, add workflow(このバッチでワークフロー関連のテーブルが作成されます)
    • 669ffd70119c, introduce_trigger
    • 7bb281b7a422, Add workflow_pauses_reasons table
    • など、最新の 788d3099ae3a, add summary index feature まで。

    エラーによる中断はなく、最後に明確なメッセージが表示されています。

    Database migration successful!
    

    その後、gunicorn が起動しています。これが期待される「完全移行成功」のパスです。

  2. バージョン組み合わせが以前の2つの落とし穴を回避していること

    • Dify が 1.12.1 にアップグレードされていること;
    • PostgreSQL が 15-alpine に変更され、PG18 に組み込まれている uuidv7() と移行スクリプトの競合問題がなくなったこと。

    この組み合わせでは、公式のデフォルト移行スクリプトはこのようなPostgresバージョンでテストされているため、workflow_schedule_plans のようなテーブルが正常に作成され、worker の poll_workflow_schedules クエリが「relation … does not exist」というエラーに遭遇することはなくなります。


今できる簡単な検証(いずれか1つを選択):

  1. DBでコアテーブルが存在するかどうかを確認します。例えば:

    SELECT table_name
    FROM information_schema.tables
    WHERE table_name IN ('workflow_schedule_plans', 'workflows', 'app_triggers');
    

    通常、結果が返されます。

  2. worker / worker_beat を起動した後、それらのログに再度次のメッセージが表示されていないか確認します。

    relation "workflow_schedule_plans" does not exist
    

    もしこのようなエラーがもう表示されないのであれば、元の問題(定期タスクが実行されない)は、今回の「再インストール + 正しいバージョン組み合わせ + 完全移行」によって解決されたことになります。

もし今後workerのログで新しいエラー(テーブル不足ではない)が表示された場合は、具体的なログを再度貼り付けていただければ、それが別の設定問題であるかどうかを確認するお手伝いをします。