[X] I have searched the existing issues, and I could not find an existing issue for this bug
Current Behavior
We recently moved from a pod-based index on the free tier to a serverless one in preparation for the migration. The script using this index started failing. What it does right now is the following:
Insert a very small number of 1536-dimensionality vectors (50-60 vectors total)
Query vectors using filters
What I'm seeing is that in step 2 we are failing to read out any vectors even though the result of step 1 is a success response. Then when I go back to check it later I am seeing that the vectors are there. I also double-checked that the upsert call is properly awaited.
My workaround was to add a blocking step in between 1 &2 in the script that polls the Pinecone index until the vectors show up. In this blocking step this is what I'm seeing:
[2024-06-06T18:24:23.350Z] - checking Pinecone for vectors...
[2024-06-06T18:24:23.350Z] - num pinecone vectors: 0
[2024-06-06T18:24:24.290Z] - checking Pinecone for vectors...
[2024-06-06T18:24:24.290Z] - num pinecone vectors: 0
[2024-06-06T18:24:24.804Z] - checking Pinecone for vectors...
[2024-06-06T18:24:24.804Z] - num pinecone vectors: 0
[2024-06-06T18:24:25.065Z] - checking Pinecone for vectors...
[2024-06-06T18:24:25.065Z] - num pinecone vectors: 59
This makes me believe that the serverless index is somehow eventually consistent but I don't think that's documented anywhere. Given that this feels like a bug to me and a bug that a lot of people will start running into as they migrate away from pod-based this week.
Expected Behavior
In step 2 it returns the vectors expected
Steps To Reproduce
Serverless pod config:
Migrated from pod-based (not sure if this is important)
1536 dimensionality
Metric = cosine
Setup a simple script as detailed above in "current behavior"
Hi @douglasqian thank you for opening. This eventual consistency is expected and documented in our limitations here. Closing this issue, but please reopen if you have any further questions.
Is this a new bug?
Current Behavior
We recently moved from a pod-based index on the free tier to a serverless one in preparation for the migration. The script using this index started failing. What it does right now is the following:
What I'm seeing is that in step 2 we are failing to read out any vectors even though the result of step 1 is a success response. Then when I go back to check it later I am seeing that the vectors are there. I also double-checked that the upsert call is properly awaited.
My workaround was to add a blocking step in between 1 &2 in the script that polls the Pinecone index until the vectors show up. In this blocking step this is what I'm seeing:
This makes me believe that the serverless index is somehow eventually consistent but I don't think that's documented anywhere. Given that this feels like a bug to me and a bug that a lot of people will start running into as they migrate away from pod-based this week.
Expected Behavior
In step 2 it returns the vectors expected
Steps To Reproduce
Serverless pod config:
Setup a simple script as detailed above in "current behavior"
Relevant log output
No response
Environment
Additional Context
No response