File Search Vector_Store_Id not persisted when creating a thread with createAndRun

API Bugs
1

If I create a thread for an assistant like this:

const threadAndRun = await client.beta.threads.createAndRun({
            assistant_id: assistantId,
            thread: {
                messages: [
                    { role: "user", content: message }
                ]
            },
            tool_resources: {
                file_search: { 
                    vector_store_ids: [vectorStoreId]
                }
            }
        });

The response indicates the tool_resource.file_search.vector_store_ids is present.

However, if I then retrieve the thread like this:

const thread = await client.beta.threads.retrieve(threadId)

The response shows the vector_store_ids is missing. It looks like this:

{
  "id": "thread_123",
  "object": "thread",
  "created_at": 1739372658,
  "metadata": {},
  "tool_resources": {
    "code_interpreter": {
      "file_ids": []
    }
  }
}

If I try to add a message or create a new run, the response indicates that the vector_store is unavailable to assistant.

In order to fix this, I have to modify the thread and add the file_search vector store AGAIN, like this:

const updatedThreadResult = await client.beta.threads.update(threadId, {
                tool_resources: {
                    file_search: {
                        vector_store_ids: [vectorStoreId]
                    }
                }
            });
   
 const retrievedThreadResult = await client.beta.threads.retrieve(threadId)

When I do this, the thread then has the vector store associated with it.

Expected Behavior

When I first create the thread via createAndRun the associated tool_resources should be persisted and used in all subsequent calls without having to modify the thread.

1 Like
2

I’ve been running into the same thing. I’m attempting to have a convo about a specific vector store in one single thread. The initial create and run will respond with context from the vector store, but when I continue the convo on that thread it loses the vector store context for all subsequent requests.

I had to use your fix to re-add the vector store on every request when the thread already exists. Obviously not an optimal solution, though. It seems the thread should hold the vector store context all the way through.