Dify 1.17.1、ナレッジベースのキー権限を縮小。ただし内蔵 Weaviate は12バージョンを順次アップグレードする必要あり

Dify 1.17.1 では、ナレッジベースの Service API にデータセット単位のキーが追加された。従来は1つのキーで同一 workspace 内のすべてのナレッジベースを読み書きできたが、新バージョンでは作成時に単一のデータセットへ紐付けられる。他のデータセットやドキュメント、検索、および dataset ID を含まないグローバルな一覧エンドポイントへのアクセスには、すべて `403` が返される。既存のキーは引き続き workspace-wide の権限を保持するため、アップグレードしただけでは最小権限の原則は自動適用されない。管理者は認証情報を再発行し、置き換える必要がある。

バックエンドでは、複数の ORM model からグローバルな `db.session` を使用するラッパーも削除され、呼び出し元が明示的に session を渡す方式へ変更された。これにより、高負荷時にリクエスト間で状態が漏れる問題や `DetachedInstanceError` の発生を抑える。3つのデータベース migration では、アカウントのメールアドレスの正規化、旧 model type の新形式への自動変換、API token と dataset の多対多の紐付け作成が行われる。このうち model type migration には可逆的な downgrade がないため、実行前のバックアップが必須となる。

最大のデプロイリスクは内蔵 Weaviate にある。イメージが 1.27.0 から一挙に 1.39.2 へ変更されたためだ。Dify は、既存のデータボリュームについて、1.28 から 1.38 まで各バージョンの最新 patch を順番に適用し、最後に 1.39.2 へ移行するよう明確に求めている。各段階で正常に停止し、検証しなければならない。これは、一度に1つの minor version だけを跨ぐという Weaviate 公式の推奨事項とも一致する。Dify のテストでは、強制終了後もオブジェクト数、BM25、ID による読み取りは正常に見える一方、`near_vector` では700個のオブジェクトのうち680個しか取得できない場合があることも示された。health endpoint の確認だけでは、HNSW インデックスの完全性を証明できない。

新バージョンではさらに、Redis の無制限な肥大化を抑えるため、エージェント実行履歴とイベントストリームのデフォルト保持期間が3日間から2時間へ短縮された。長期間のデバッグデータに依存するチームは、`DIFY_AGENT_RUN_RETENTION_SECONDS` を明示的に設定する必要がある。アップグレードの受け入れテストには、実際のナレッジベースに対するベクトル検索、model provider の読み込み、大規模 workflow の同期テストを含めるべきだ。外部 Weaviate、他のベクトルデータベース、または新規データボリュームを使用する環境は、この段階的 migration の要件による影響を受けない。