プラグインインストール失敗、無限ループに陥る。インストールを止めるには？

議論
9

お二人の状況は、すでに手がかりを十分に提供してくれています。1.11.4に特化して、「停止方法 + クリーンアップ方法 + 再びフリーズするのを避ける方法」をまとめます。

一、現在発生している現象はどのような状況ですか？

Niklaus1028のログから判断すると、おおよそ次のとおりです。

  • /plugin/\u003cplugin-id\u003e/management/install/tasks、/dispatch/model/schemaなどのAPIを繰り返しポーリングしています。
  • その途中で以下の現象が発生しています。
    • task xxx timed out
    • record not found（SELECT * FROM \"plugin_declarations\" WHERE plugin_unique_identifier = 'alipay/alipay_plugin:0.1.0@...'）

ao_zhangの記述と合わせると：

  • UIには常に「プラグインをインストール中」と表示されています。
  • バックグラウンドタスクでTask timed out but not properly terminatedが発生しています。
  • 同じプラグイン（Tongyi / Alipayなど）のインストールタスクが繰り返し作成されています。

これは次のことを示しています。

  1. 特定のインストールタスクがタイムアウトしましたが、その状態が「終了」として正しくマークされなかったため、デーモンプロセスが常にインストール中であると認識しています。
  2. 一部のプラグインのplugin_unique_identifierがDBで検索できない（record not found）にもかかわらず、インストールプロセスが引き続きスケジュールされ、状態がさらに混乱しています。

二、まず「停止」——デーモンプロセスがタスクを更新し続けないようにする

サーバーでプラグインデーモンコンテナを一時停止します。

docker stop docker-plugin_daemon-1

効果：

  • 新しいインストールタスクの作成を直ちに停止し、Task timed out...の更新を停止します。
  • その後のクリーンアップが容易になります（クリーンアップしたばかりなのに、新しいタスクでまた更新されるのを防ぎます）。

クリーンアップ後に再起動します。

docker start docker-plugin_daemon-1

三、ローカルデプロイ環境でAuthorization（Bearer Token）を取得する方法

お二方とも1.11.4のdocker-compose自己ホスティングを使用しており、ローカルであっても、フロントエンドがバックエンドにアクセスする際には自動的にBearer Tokenが付与されますが、普段は表示されません。

手順（Chrome/Edgeの場合）：

  1. ブラウザでDify管理画面（例：http://サーバーIPまたはhttp://localhost）にアクセスし、管理者アカウントで正常にログインします。
  2. F12を押して開発者ツールを開き、「Network / ネットワーク」パネルに切り替えます。
  3. ページ内で他のメニューを適当にクリックします（例：「アプリケーション」や「データセット」などに入ります）。これにより、APIリクエストが送信されることを確認します。
  4. Networkリストで、/console/api/...のようなパスのリクエストを見つけてクリックします。
  5. 「Headers / リクエストヘッダー」で以下を見つけます。
    Authorization: Bearer xxxxxxxx...
  6. Bearerの後ろの長いトークン文字列をコピーします（自分だけが使用し、フォーラムには投稿しないでください）。

このトークンがあれば、サーバー上でcurlを使ってクリーンアップAPIを呼び出すことができ、「クラウド固有」のAuthorizationは不要になります。

四、 「フリーズしたインストールタスク」のクリーンアップ

以前の「プラグインのインストールに失敗した後、UIに常に1つのプラグインがインストール中と表示される」という投稿で、専用の「インストールタスクの状態をクリーンアップする」POST APIとボディテンプレートが提供されています。そちらの説明に従って操作してください。

呼び出しの一般的な書き方は以下のとおりです（パスとボディは、その投稿で提供されている実際の内容に置き換えてください）。

curl -X POST "http://\u003cあなたのバックエンドアドレス\u003e/\u003cその投稿のAPIパス\u003e" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer \u003c前のステップでコピーしたトークン\u003e" \
  -d '{
    ... ここにその投稿のJSONボディを入力 ...
  }'

注意：

  • \u003cあなたのバックエンドアドレス\u003e：
    • 公式のdockerディレクトリから直接起動している場合、通常Nginxはフロントエンドとバックエンドの両方を80番ポートに公開しているため、http://\u003cサーバーIP\u003eまたは現在Difyにアクセスできるアドレスを直接使用できます。
    • カスタムのリバースプロキシを使用している場合は、フロントエンドがDifyに正常にアクセスできるドメイン/ポートを使用してください。
  • パスとリクエストボディは、古い投稿で提供されているものを完全に守ってください。推測しないでください。他のプラグインやタスクの状態を誤って削除する可能性があります。

呼び出しが成功した後：

  • Difyページを更新してください。
    • 右上隅の「プラグインをインストール中」の表示が消えるはずです。
    • フリーズしていたプラグインは「未インストール」または失敗状態になるはずです。

五、クリーンアップ後もすべてのプラグインがタイムアウトする場合、どの方向を調査すべきか？

お二方とも1.11.4であり、さらに：

  • ローカルインストール（difypkgのアップロード）もタイムアウトします。
  • マーケットプレイスからのインストールもタイムアウトします。
  • ログに連続してtimeoutとrecord not foundが表示されます。

これは通常、単一のプラグインの問題ではなく、プラグインの実行環境自体が異常であることを示しています。いくつかの重要な調査方向：

1. マシンのパフォーマンスとDockerリソース

プラグインのインストールでは、プラグインコンテナ内にPython仮想環境を作成し、依存関係をダウンロードします。マシンが「逼迫」している場合：

  • CPU/メモリ不足
  • Dockerに割り当てられたリソースが少なすぎる

これらすべてがタスクの実行速度を非常に遅くしたり、タイムアウトさせたりする可能性があります。対応する操作：

  • マシンが少なくとも以下のリソースを持っていることを確認します。
    • 2コアCPU、4GB以上のメモリ（公式の最低要件では8GBがより安定していると推奨されています）。
  • Docker Desktop（Mac/Winの場合）でCPU/メモリを適切に調整します。
  • サーバー上でtop/htopを使用して、インストール時のCPU/MEMがフル稼働しているかどうかを観察します。

2. プラグインコンテナから外部ネットワーク/Pythonソースへのアクセスがスムーズか

他のプラグインの投稿から判断すると、1.11.xバージョンでのインストール失敗の多くは、次の原因によるものです。

  • デフォルトのPyPIソースに接続できない、または非常に遅い。
  • ネットワークポリシーまたはプロキシがプラグインコンテナの外部ネットワークへのアクセスをブロックしている。

調査：

  1. プラグインデーモンコンテナに入ります。
    docker exec -it docker-plugin_daemon-1 /bin/bash
  2. コンテナ内で試します。
    ping pypi.org
curl -I https://pypi.org/simple
    完全に接続できない、または遅延が非常に高い場合、インストール時にタイムアウトしやすくなります。

考慮すべき点：

  • .envでプラグインに国内のPythonソースを設定する（公式があなたのバージョンでサポートしている場合）。
  • または、ホストレベルでネットワークプロキシを設定し、コンテナが外部ネットワークに正常にアクセスできるようにします。

3. record not foundは何を意味しますか？

ログに次のような表示があります。

SELECT * FROM "plugin_declarations" WHERE plugin_unique_identifier = 'alipay/alipay_plugin:0.1.0@...' ... record not found

これは次のことを意味します。

  • プラグイン宣言がデータベースに正常に書き込まれていない。
  • しかし、インストールプロセスの後続ステップでは、このplugin_unique_identifierに基づいて検索を続けていますが、レコードが見つかりません。

APIでインストールタスクをクリーンアップした後：

  • プラグインマーケット/プラグイン管理ページを再度開くことをお勧めします。
  • 古いゴミの状態が重なるのを避けるため、まず簡単なプラグインを1つだけインストールしてテストします（例えば、組み込みの公式デモプラグイン）。
    • 簡単なプラグインもタイムアウトする場合、それは「環境レベルの問題」です。
    • 簡単なプラグインがOKで、特定のいくつかのプラグインが失敗する場合、それらのプラグインの依存関係とネットワークに焦点を当てて確認します。

六、APIクリーンアップでも解決しない場合、残された「状態のリセット」の2つの方法（リスク高）

データのバックアップが可能で、データベース操作の経験がある場合にのみ検討してください。

  1. スタック全体の停止 + データベースのバックアップ

    docker compose down

    Postgresコンテナがdocker-db_postgres-1という名前だと仮定して、バックアップします。

    docker exec -t docker-db_postgres-1 \
  pg_dump -U \u003cdb_user\u003e \u003cdb_name\u003e > dify_backup.sql

  2. データベースに入り、プラグイン関連の「インストールタスク」と「インストール中状態」を削除するか、失敗に変更します。
    このステップは、バージョンによってテーブル名/フィールドが若干異なります。自分でフィールド名を推測することは推奨しません。他のものを誤って削除する可能性が非常に高いためです。
    どうしてもこの方法を取る必要がある場合は、別途スレッドを立てるか、ここに以下の情報を追加することをお勧めします。

    • docker-compose.yml内のDifyバージョンとPostgres関連の設定。
    • \dtでプラグイン関連テーブルの名前と構造のスクリーンショット。
      その後、具体的なSQLについて一緒に検討しましょう。

七、次のステップとして、このようにフィードバックを続けることで、正確な特定が容易になります

お二方それぞれ、以下の情報をこの投稿に補足することをお勧めします。

  1. 実行：

    docker logs docker-plugin_daemon-1 -n 200

    Task timed out but not properly terminatedとrecord not foundを含むログの該当箇所を、マスクして貼り付けてください。

  2. 上記の手順でAuthorization: Bearer ...を取得し、「インストールタスクのクリーンアップ」POST呼び出しを一度試行します。

    • 呼び出しに使用したAPIパスは何ですか？
    • 返されたHTTPステータスコードは何ですか（200 / 4xx / 5xx）？
    • 呼び出し後、UIを更新して、「プラグインをインストール中」の表示は消えましたか？

  3. クリーンアップ後、最も簡単なプラグインを再度インストールしてみて、依然としてTask timed out but not properly terminatedが統一して報告されるかどうかを確認します。

以下のことが確認できれば：

  • クリーンアップAPIがフリーズしたタスクを正常に「ゼロに戻せる」こと。
  • しかし、新規インストールは依然としてタイムアウトすること。

その場合、基本的には「環境/ネットワーク/リソース」の問題であり、単なる一時的なダーティデータではないと判断できます。その後、環境最適化のガイダンスを具体的に提供したり、より新しいバージョンへのアップグレードを検討するよう提案したりできます（後続バージョンでは、プラグインのインストールタイムアウトとタスククリーンアップに関して継続的に修正が行われています）。

:books: 関連ドキュメント

もし可能であれば、上記の「停止 + トークン取得 + クリーンアップAPI呼び出し」の3つのステップをまず実行し、その実行結果を返信してください。そうすれば、根本原因を「環境問題かバージョンバグか」に絞り込むことができます。