qdrant / qdrant/qdrant-client

Don't write .lock file when loading from an existing collection

Open
#765 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
1.4k
Forks
301
Avg merge
2d 9h
Merged PRs (30d)
37

Description

I have stored a qdrant collection locally on my computer to access it for testing purposes. I am building a chatbot app in gradio and it requires to load the app.py many times to develop it in iterations.

However, every time I load the collection a .lock file is automatically created which I have to manually delete each time when loading app again for my application. Otherwise I run into following error:

RuntimeError: Storage folder qdrant/ is already accessed by another instance of Qdrant client. If you require concurrent access, use Qdrant server instead.

The code to load the collection is as follows:

vectors = QdrantVectorStore.from_existing_collection(
    path="qdrant/", 
    collection_name="uganda-documents",
    
    embedding = HuggingFaceEmbeddings(
        model_kwargs = {'device': device},
        encode_kwargs = {'normalize_embeddings': bool(int(config.get('retriever','NORMALIZE')))},
        model_name=config.get('retriever','MODEL')
    )
)

I would like to either automatically delete the .lock file or to not create it at all in the first place. Is this possible within Qdrant or do I have to build a manual work around?

I know I could simply add something like a os.remove("qdrant/.lock") but it seems not very intuitive.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the QdrantVectorStore.from_existing_collection entry point used in app.py and trace how the local qdrant/ storage client is opened and released. Check the existing local-storage tests, if available, for lock-file behavior. Done means repeatedly loading the existing collection does not leave a lock that blocks the next load.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
databases
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.