File_search returns results from deleted files no longer linked to the vector store

[wouter.steenkist]

Issue description

I’m encountering an issue where file_search results include entries from files that have already been deleted and disconnected from the vector store.

Details

I have a vector store:

vector_store_id: vs_68f856a359e0819181fd825fe4e77eb3

When running a file_search, I receive results like the following:

[4] => Array
(
    [file_id] => file-4qztCVCm3D3doi5sQF6jMn
    [filename] => dataset_786_c1_20251027.json
    [score] => 0.5252
    [text] => price.0: 0
shipping_weight: 11750
sizex: 47
sizey: 40
sizez: 63
sku: 21335
...
)

However:

• file-4qztCVCm3D3doi5sQF6jMn no longer exists (it was deleted from my account),

• It was explicitly unlinked from the vector store before deletion,

• Yet it still appears in search results for that vector store.

Expected behavior

Deleted (or unlinked) files should not appear in file_search results for an existing vector store.

What I’ve verified

• The vector store itself (vs_68f856a359e0819181fd825fe4e77eb3) still exists.

• The old file ID returns a 404 when queried.

• I’ve re-indexed and even re-uploaded new files, but stale search results persist.

• The issue seems to be cache or stale index related.

Environment

• API: OpenAI Realtime + Vector Stores

• Endpoint: file_search

• Date observed: November 2025

• Language: PHP backend calling the OpenAI API directly

Question

Is there a known issue or delay in index cleanup after deleting/unlinking files from a vector store?
If not, how can we force a reindex or purge stale embeddings that refer to deleted files?

[_j]

Status: “Known” - as evidenced here where I describe that a week ago:

@_j

The issue retrieving files has been reported in a previous post, but is part of multi-faceted issues with vector stores that have continued for days. Other symptoms are delays in updating server objects on upload (breaking SDK polling), incomplete file listings, non-deleting file attachments, missing endpoint for a platform site service - and plainly, Assistants that cannot answer because the file search tool returns an error instead of retrieving information and loading tokens.

OpenAI status: unknown, uncaring, unresponsive (a re-compilation of 100 forum topics backing my assertion would also resolve nothing.)

You can add that complete corruption and failure of listings:

500 Error Loading Vector Stores

However, if the count is correct - you request 10 and get 5 results, or then 9 returns 0 - it is still a messed-up API database, either your org or the platform. You can finally see if that pattern of return counts is replicable or happenstance. This will take OpenAI repair. You can see if you can live with self-management of IDs; creating a vector store, logging, retrieving, and ensuring you have a container you can use. You have to live with not being able to list response IDs or threads or…

There’s an intolerable amount of complete outages and ongoing issues going back months. You would not expose your reputation by exposing your clients to OpenAI’s vector stores.

Changes may be related to data residency, project scoping, database propagation. You can ensure that one project API key is doing all the vector store interactions, from creation, upload, and population, inference, through deletions and cleanup.

[olivier.cuny]

This sounds like it is connected to this issue:

Vector Store List Files Bug - Deleted files show as In Progress

Given the fact that the bug exists in the first place, it has not been fixed in months most likely, It’s probably fair to assume that the whole vector store is probably a vaporware. I would have thought the vector store would have actually been an important part of the effort to get more developers to stay in an Open AI ecosystem. It ties nicely with other SDK, it makes it effortless in many ways. Instead it is pushing my team (Tier 5 customer) to look for alternatives ASAP and reduce our indep…

If you run this endpoint: https://platform.openai.com/docs/api-reference/vector-stores-files/listFiles
I’ll bet you that the files in question are getting returned as “in_progress”

@_j is right that the whole vector store handling is worrysome and probably not worth the risk