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

[_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.