mirror of
https://github.com/langgenius/dify-official-plugins.git
synced 2026-07-21 17:45:23 -04:00
documents in pipeline keep in status queuing #862
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @simpsonyang on GitHub (Dec 9, 2025).
Self Checks
Dify version
1.10.1
Plugin version
0.0.4
Cloud or Self Hosted
Self Hosted (Docker)
Steps to reproduce
I created a pipeline with the markitdown template, then upload 3 files, but the status keeps in Queuing. I have already set FILES_URL=http://api:5001 in my .env file.
✔️ Error log
Exception in thread Thread-106 (_retriever):
Traceback (most recent call last):
File "/usr/local/lib/python3.12/threading.py", line 1075, in _bootstrap_inner
self.run()
File "/usr/local/lib/python3.12/threading.py", line 1012, in run
self._target(*self._args, **self._kwargs)
File "/app/api/core/rag/retrieval/dataset_retrieval.py", line 652, in _retriever
documents = RetrievalService.retrieve(
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/api/core/rag/datasource/retrieval_service.py", line 107, in retrieve
raise ValueError(";\n".join(exceptions))
ValueError: Query call with protocol GRPC search failed with message extract target vectors: class Vector_index_0d746ee2_719f_4c3b_b0ed_dd57a6dff939_Node does not have named vector default configured. Available named vectors map[].
2025-12-10 03:45:50.695 INFO [Thread-105 (_retriever)] [_client.py:1038] - HTTP Request: GET http://plugin_daemon:5002/plugin/97098ea7-f8e8-4ba4-a25b-bb1d22ccc1ec/management/models?page=1&page_size=256 "HTTP/1.1 200 OK"
/usr/local/lib/python3.12/json/decoder.py:354: ResourceWarning: unclosed <socket object, fd=57, family=2, type=1, proto=6>
obj, end = self.scan_once(s, idx)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/local/lib/python3.12/json/decoder.py:354: ResourceWarning: unclosed <socket object, fd=53, family=2, type=1, proto=6>
obj, end = self.scan_once(s, idx)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/local/lib/python3.12/json/decoder.py:354: ResourceWarning: unclosed <socket object, fd=49, family=2, type=1, proto=6>
obj, end = self.scan_once(s, idx)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/local/lib/python3.12/json/decoder.py:354: ResourceWarning: unclosed <socket object, fd=48, family=2, type=1, proto=6>
obj, end = self.scan_once(s, idx)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/app/api/core/model_runtime/entities/common_entities.py:12: ResourceWarning: unclosed <socket object, fd=44, family=2, type=1, proto=6>
@model_validator(mode="after")
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/app/api/core/model_runtime/entities/common_entities.py:12: ResourceWarning: unclosed <socket object, fd=50, family=2, type=1, proto=6>
@model_validator(mode="after")
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/app/api/core/model_runtime/entities/common_entities.py:12: ResourceWarning: unclosed <socket object, fd=51, family=2, type=1, proto=6>
@model_validator(mode="after")
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/app/api/core/model_runtime/entities/common_entities.py:12: ResourceWarning: unclosed <socket object, fd=52, family=2, type=1, proto=6>
@model_validator(mode="after")
ResourceWarning: Enable tracemalloc to get the object allocation traceback
@dosubot[bot] commented on GitHub (Dec 9, 2025):
Your pipeline is stuck in "Queuing" because the vector index in your vector database (like Qdrant) is missing a named vector called "default", which is now required by the gRPC search protocol. Dify's current collection creation logic uses a legacy configuration that doesn't define named vectors, so when the retrieval service tries to search, it fails with the error about the missing "default" named vector, and the pipeline can't proceed.
To fix this, you need to recreate the affected vector collection with a named vector called "default" in its configuration. In Qdrant, this means dropping the problematic collection (e.g., Vector_index_<dataset_id>_Node) and letting Dify re-create it, or manually creating it with the correct named vector schema. After that, re-upload your documents so the embeddings are stored in the new collection. This will allow the retrieval service to work and your pipeline to move past "Queuing" status.
This issue is due to recent changes in Qdrant's gRPC client expectations, and Dify's collection creation logic hasn't yet been updated to always use named vectors in all cases. More details on how the vector index is built and why the error occurs can be found in the Dify codebase and recent pull requests (source).
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@simpsonyang commented on GitHub (Dec 10, 2025):
@dosu, there is no Qdrant in my Dify dockers, I can only see Weaviate.
@dosubot[bot] commented on GitHub (Dec 10, 2025):
The error about the missing named vector "default" is a known issue with Weaviate after upgrading Dify or Weaviate. This happens because older Weaviate collections (created before Dify 1.9.2 or Weaviate 1.27.0) use an outdated schema that doesn't include the required "default" named vector, which Dify now expects for search and retrieval. The upgrade process does not automatically migrate these collections, and the vector configuration in Weaviate is immutable, so you can't patch it in place.
To fix this, you need to re-index or re-upload the affected knowledge/documents so the collections are recreated with the correct named vector configuration. Changing the embedding model of the knowledge base can also trigger an automatic index rebuild with the right schema. For large knowledge bases, scripting the export/import or re-upload is recommended. There is no automated migration script—manual intervention is required. If the error persists after re-ingesting, check the Weaviate schema via API or UI to confirm the collection has a named vector "default" configured, and if not, manually delete and recreate the collection. More details are in the official Weaviate migration guide for Dify
(source 1, source 2, source 3).
If your pipeline is still stuck in "Queuing" after fixing the vector schema, double-check that your Celery worker is listening to both the pipeline and priority_pipeline queues, and that all required services (Redis, vector DB, embedding provider) are healthy.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@simpsonyang commented on GitHub (Dec 10, 2025):
意思明白了，还是找DS给了详细的操作步骤，解决了。