Dify Proposes Qdrant Deletion Scope Fix to Prevent Shared Attachment IDs from Affecting Other Datasets

On November 4, the Dify community proposed PR #45586 to address accidental cross-dataset deletion in the Qdrant vector store interface. According to the submitter, when two datasets share the same collection and have the same attachment ID, running delete_by_ids on dataset A could also delete vectors belonging to dataset B. The fix tightens the deletion condition so it must match both the specified document ID and the dataset’s group_id. Fix proposal

The technical issue concerns the scope of application-level identifiers. A Qdrant point contains a vector and an optional payload. Qdrant’s official delete API supports specifying point IDs directly, as well as selecting data with payload filters. When datasets share a collection, the application must include its own data boundary in the conditions so the database performs the deletion within that scope. Qdrant official documentation

The submitter says the tests used the official SDK’s local engine with a pinned qdrant-client version, 1.9.0. In the shared-attachment scenario, the unfixed code deleted two points from the other dataset; after the fix, points belonging to other datasets and unrelated data were retained. All 16 tests in the provider test module passed. These results come from the test records published by the submitter; they do not establish that a cloud backend or the full deployed API has been validated. Cleaning up attachments during document deletion is also a separate task. Validation scope

For RAG teams, based on the reproduction conditions above, accidental deletion could leave an untouched knowledge base with less retrievable content, reducing the evidence available to support answers. Engineers can first review how collections are shared and add deletion regression cases with duplicate attachment IDs across datasets, checking that both target and non-target data behave as expected.

As of the time of review, Dify’s November 5 commit list included the fix, but the PR page still showed it as open, leaving the status inconsistent. What can be confirmed is that the issue description and proposed fix are public; it is premature to claim that a particular official release has resolved it. The next steps are to track the merge record, release tags, and tests in deployed environments. Main branch commit list