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

議論
5

まず、以下の手順で段階的にトラブルシューティングと「停止」を行い、Authorization を必要とするPOSTインターフェースはできるだけ使用しないようにしてください。

1. まずプラグインデーモンが繰り返しリトライしているか確認する

デプロイサーバーで実行します（一度通知されています）：

docker logs docker-plugin_daemon-1 -n 200

最近のログで以下のような繰り返しがないか確認してください：

  • 特定のプラグインのインストールタスク
  • 常に Task timed out but not properly terminated と報告されている

もしそうであれば：

  • おそらく「インストール中」のタスクがスタックしており、プラグインデーモンが繰り返しリトライしています。

まず「停止させる」ために、このコンテナを一時的に停止できます：

docker stop docker-plugin_daemon-1

これにより、失敗したインストール記録が更新され続けるのを一時的に阻止できます。
（その後再起動するには：docker start docker-plugin_daemon-1）

2. POSTインターフェースを使用せずに、ローカルのAuthorizationをどのように取得するか？

ローカルデプロイであっても、フロントエンドがDifyにアクセスする際にはBearerトークンが送信されますが、これはブラウザが自動的に行っています。

このトークンを次のように取得し、別のスレッドで見たPOSTインターフェース（「プラグインインストール中ステータスのクリア」インターフェース）を呼び出すために使用できます：

  1. ブラウザでDifyのウェブページ（例：http://localhost:3000 またはご自身のドメイン）を開き、通常通りログインします。
  2. ブラウザの開発者ツールを開きます：
    • Chrome/Edge：F12 → 「Network / ネットワーク」タブを選択します。
  3. ページ上でバックエンドにアクセスする任意のページ（例：「スタジオ」「アプリ」など）をクリックします。
  4. Networkパネルで、リクエストパスが /console/api/... のようなインターフェースを見つけてクリックします。
  5. 「Headers / リクエストヘッダー」で Authorization フィールドを見つけます。通常は次のようになります：
    Authorization: Bearer xxxxxxx...
  6. Bearer の後ろにあるこの長いトークンをコピーします。（他人に漏洩しないよう注意してください）

これで、ローカルデプロイの Authorization 値が手に入り、クラウドと同様にその修復インターフェースを呼び出すことができます。

3. 取得したトークンを使用して「インストール中タスクのクリア」インターフェースを呼び出す

参照したスレッドで、具体的なインターフェースパスとメソッドはすでに確認されているはずです。通常は POST リクエストです。

curl（サーバー上で）を使用して送信できます：

curl -X POST "http://<あなたのバックエンドアドレス>/xxx/xxx" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <あなたが先ほどコピーしたトークン>" \
  -d '{
    // そのスレッドのbodyに従って入力
  }'

いくつか注意点があります：

  • <あなたのバックエンドアドレス>：デフォルトのdocker-composeを使用している場合、通常は次のようになります：
    • ホストブラウザからアクセス：http://<サーバーIP>:3000
    • ただし、APIの実際のバックエンドポートは5001/8000などである可能性があり、ご自身の設定（docker-compose.yml内のAPIサービスのマッピングを参照）と一致させる必要があります。
  • インターフェースパス、bodyパラメータは、参照したスレッドに完全に従って入力してください（他の記録を誤って削除しないように）。

呼び出しが成功したら、Difyページを更新すると、通常は次のようになります：

  • 右上隅の「プラグインインストール中」の通知が消えます。
  • Tongyi（通義）プラグインは「未インストール」または失敗状態になり、後で再インストールを試すことができます（まずイメージ/ネットワークの問題をトラブルシューティングすることをお勧めします）。

4. どうしてもAPIを使えない/使いたくない場合、より「強硬な」方法も検討できます（注意）

この方法はリスクが高く、ある程度のデータベース操作経験があり、データベースのバックアップを受け入れられる場合にのみ適しています：

  1. Dify関連コンテナを停止します（書き込み競合を避けるため）
    docker compose down
  2. データベースコンテナ内のデータ（Postgres）をバックアップします：
    • Postgresコンテナ名を見つけます。例えば、docker psで dify-postgres-1 と表示されます。
    • pg_dump を使用してエクスポートします：
      docker exec -t dify-postgres-1 pg_dump -U <db_user> <db_name> > dify_backup.sql
  3. データベースに入り、「プラグインインストールタスク」に関連するテーブルを見つけ、ステータスを installing / pending から failed に変更するか、そのレコードを直接削除します。

ただし、バージョンによってテーブル構造が変更されたり、フィールド名が完全に同じではないため、この手順に進む場合は、docker-compose.ymlのバージョン番号、データベース情報、および関連するテーブル構造の一部を貼り付けてから議論することをお勧めします。誤操作を避けるためです。

5. 今、まず2つのことを返信することをお勧めします

  1. サーバー上で実行します：

    docker logs docker-plugin_daemon-1 -n 200

    重要なエラー（Task timed out but not properly terminated の前後数行を含む）をスレッドに貼り付けてください。

  2. 上記のステップ2に従って、ブラウザで Authorization: Bearer ... を取得し、トークンをキャプチャできることを確認してください。疑問がある場合は、マスクされたリクエストヘッダーのスクリーンショットを貼り付けても構いません。

ログとあなたのバージョン（1.11.4）の情報があれば、今後もスタックした場合、それが現在のバージョンの既知の問題なのか、それともTongyi（通義）プラグイン自体のインストール（例：ネットワーク、Pythonソース、イメージ）の問題なのかをより正確に判断できます。

:books: 役立つ可能性のあるドキュメント（問題関連）

:label: バージョン情報

  • 現在のバージョンはv1.11.4です。プラグインシステムはかなり完成していますが、プラグインのインストール/依存関係のインストールに関する問題は、今後のバージョンで継続的に修正されています。もし後で公式リリースで「プラグインインストールタイムアウト/インストール中にスタックする」といった問題の修正が言及された場合、可能であればアップグレードも検討することをお勧めします。