Vector Store file delete is not removing the file from vector store

API Bugs
1

I am using vector store api to delete the file from Vector Store. The response is successful, but it’s still showing the file in the vector store.

Here is the API:

https://api.openai.com/v1/vector_stores/vs_69fc5568ff8481919cddb7afc0474a4a/files/file-9UrFabvtT5bvPnjoNMD44t

getting response:

{
    "id": "file-9UrFabvtT5bvPnjoNMD44t",
    "object": "vector_store.file.deleted",
    "deleted": true
}

But still getting the file in the vector store files list.

image
image1565×776 48.8 KB

I have tried multiple times to delete the file, but it’s not being deleted from VectorStore.

Note: I have been getting this problem since yesterday only; before that, it was working fine.

2

Hi and welcome to the community!

Thanks for raising this.

There is a known timing gap when a file is added to or removed from a vector store. If you list the vector store contents immediately afterward, you may receive unexpected results.

I assume you already tried this, but can you confirm whether waiting a few seconds after deleting the file before listing the files attached to the vector store changes the result?

3

Thank you for the reply.

And no, it is still not deleted from the vector store. The file is still available and still getting the same response when trying to delete that same file from vector store.

4

Adding one more thing: are you checking the vector store file object specifically or the underlying file object?

From the docs, files can be removed from a vector store either by deleting the vector store file object or by deleting the underlying file object. Deleting the underlying file object removes it from all vector store and code interpreter configurations across assistants/threads in the organization.

Docs:

So if it still appears specifically in the vector store files list after waiting/retrying, that may need Support/staff to inspect. But if it appears elsewhere as a file object, that may involve the separate file delete endpoint.

5

We’re seeing the same issue. Deleting a VSF returns 200, but several hours later still not actually deleted.

6

I tested this on my side, but couldn’t reproduce it. Removing the file from the vector store worked for me.

One thing I’d still check is whether you only deleted the vector store file object or if you also tried deleting the underlying file object. Since those are separate, that distinction may matter here.

If it still persists after waiting/retrying and checking that, I’d probably contact Support through the Help Center with the vector store ID, file ID, response details, timestamps and screenshots.

https://help.openai.com/en

7

Hello, we are also experiencing the same issue since may 7th: it is impossible to remove a file from a vector store, despite detaching it from the vector store or deleting it via the API file. The files are still present in the vector store several days later and are included in the estimated usage…

8

Hello, same here. Started on 7th of May. File removal still being somehow ‘in progress’. Due to this, we have few vector stores which we cant access anymore. API returns success when deleting file from vs, failing then when removing it from files

image
image714×400 24.2 KB

9

That sounds like the same issue, especially since it persists several days later and affects estimated usage.

If both removing the vector store file object and deleting the underlying file object still leave it visible/counting in the vector store. Like I already recommended in the post above, that this seems worth escalating to Support with the vector store IDs, file IDs, timestamps, API responses and screenshots.

Maybe @OpenAI_Support can also take a look here, but they would likely still ask everyone affected to open a Support ticket so they can investigate the account/project-specific details properly.

I also came to think of a separate issue that still could maybe be connected. There have also been separate reports of PDF/DOCX files failing during vector store processing/upload, which I could reproduce on my side with a PDF. I don’t know if that is connected to this deletion/removal issue, but both seem to involve vector store file processing/state.

10

Hey everyone, Our team is looking into this issue. We will provide an update shortly. Thanks for flagging!

11

Hello. Any news ? The problem still persists and is affecting more of our agents. Thanks for any update

12

Hey Everyone, This issue should now be resolved. Our engineering team has deployed a fix. Please let us know, if you are still facing an issue. Thank you!

13

Thank you for fixing the issue. It seems to be working now. But there seems to be another error now. The response of delete is the same for any file ID to be deleted. No matter which store is selected, the response is the same. For example, I have a file file-ADnWL7dAg8HKXPgqzEyyxd in store vs_69f8235f687081919e9c5f2dabcbda3d And when I try to delete this file from another store, the response is success (even when the file is not actually deleted)

I tried to delete a file (file-ADnWL7dAg8HKXPgqzEyyxd which originally belongs to vs_69f8235f687081919e9c5f2dabcbda3d store ) from another store vs_69fc5568ff8481919cddb7afc0474a4a and got a successful response; however, the file is not deleted in this case (which is expected, since the file doesn’t belong to that store). It’s just about the response of the delete API.

image
image1565×269 28.9 KB

14

deletions seems to work now (just a quick test done), prod agents are syncing overnight, so I can confirm tomorrow. Connected issue: we have several (just found 6-7) vector stores which got corrupted by this issue. We do not see any files using web or when listing them via api, getting errors. Is that something you are working on ? Or how to identify what happened and how to fix that ?

image
image769×424 19.9 KB

15

Hey everyone, the core issue is fixed now but if there are secondary issues with vector store, we request you to please open a support request at support@openai.com. Since resolving those will require personal details which we cannot attain in the public forum. Apologies.