Back Home

LLMOps 與向量資料庫

Dify 1.17.1 Narrows Knowledge Base Key Permissions, but Bundled Weaviate Must Be Upgraded Sequentially Across 12 Versions

The latest Dify release adds dataset-scoped API keys and explicit database sessions, while shortening agent event retention to control Redis growth. Existing deployments using the bundled Weaviate cannot simply update the image; otherwise, objects may remain readable even as vector retrieval becomes permanently impaired.

The original uploader was Ggia at Greek Wikipedia. · CC BY-SA 2.5 · Image source
zh-Hant

Dify 1.17.1 adds dataset-scoped keys to the Knowledge Base Service API. Previously, a single key could read and write all knowledge bases in the same workspace. The new release allows a key to be bound to one dataset when created and returns `403` for all other datasets, documents, retrieval operations, and global listing endpoints that do not include a dataset ID. Existing keys retain workspace-wide permissions, so upgrading alone does not automatically enforce least privilege; administrators must still reissue and replace credentials.

The backend also removes wrappers around the global `db.session` from several ORM models, requiring callers to pass sessions explicitly instead. This reduces cross-request state leakage and `DetachedInstanceError` occurrences under heavy load. Three database migrations normalize account email addresses, automatically convert legacy model types to the new format, and create many-to-many bindings between API tokens and datasets. The model type migration has no reversible downgrade, so a backup is required before it is run.

The greatest deployment risk comes from the bundled Weaviate image, which jumps directly from 1.27.0 to 1.39.2. Dify explicitly requires existing data volumes to pass sequentially through the latest patch release of every version from 1.28 through 1.38 before finally moving to 1.39.2, with a clean shutdown and verification at every step. This aligns with Weaviate’s official recommendation to upgrade only one minor version at a time. Dify’s tests also show that a forced termination can leave the object count, BM25 results, and ID-based reads looking normal while `near_vector` retrieves only 680 of 700 objects. Checking the health endpoint alone is therefore insufficient to prove that the HNSW index is intact.

The new release also reduces the default retention period for agent run records and event streams from three days to two hours to curb unbounded Redis growth. Teams that rely on long-term debugging data must explicitly configure `DIFY_AGENT_RUN_RETENTION_SECONDS`. Upgrade acceptance testing should include real knowledge base vector queries, model provider loading, and synchronous tests of large workflows. Deployments using an external Weaviate instance, another vector database, or a new data volume are not subject to the sequential migration requirement.

Sources

  1. Dify v1.17.1 — Bug Fixes and Improvements
  2. Migration and Upgrades