-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error Occured in Bulk OperationError: Partition key error. Either the partitions have split or an operation has an unsupported partitionKey type #20162
Comments
attached logs as wel |
@developer-ankursingh - we are investigating this issue. @sajeetharan can you please look into this ? |
Thanks for the update @sajeetharan . We can also have a session if possible with your team to demo the issue. Please let us know since it is impacting our project developement . |
@developer-ankursingh From the image looks like this happens in the stage environment right? We have checked the backend logs, we are able to see the 410 errors as well on this account on 02/02/22, just wanted to confirm if this is only for deletion. We'll schedule a call to understand once we analyze the code and check with backend team. |
@sajeetharan It is happening in SIT & STAGING but not in DEV. Just to confirm this isssue pops up only for DELETE operation for SIT & STAGING containers only but same code is working fine for other containers (all environments). It would be really nice if we can have a call where we can give you a walkthrough of the code. |
@developer-ankursingh Sorry for the delayed response, we were able to identify your requests in the backend and it looks like an issue to be on the SDK, which related to cache which maintains the partition key range. We will work on this fix soon. |
@sajeetharan Thank you for the update ! Let us know whenever you push out the fix so that we can validate and confirm. |
Suggestions to resolve the issue,
An even better option would be to fix this in the gateway. When the backend bubbles up a 410 to the gateway during bulk it could refresh its own internal partition map and reroute to the correct partition. |
Thanks @sajeetharan! @developer-ankursingh reopen if needed. |
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @bkolant-MSFT, @sajeetharan, @pjohari-ms. Issue DetailsAzure based dependencies being used - Describe the bug To Reproduce Expected behavior Screenshots
Additional context
Using above links, we can see the code written in Azure Cosmos Node JS library and the exception is being thrown from the library itself based on some internal min-max range for partition key. From our side, we cannot do much as of now to debug this further so raising a ticket here for further help.
|
Hi @developer-ankursingh, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support. |
Azure based dependencies being used -
@azure/cosmos":"^3.15.1"
@azure/identity": "^2.0.1"
Describe the bug
We have been using Azure Cosmos library with Azure identity liberary for RBAC mechanism to perform bulk delete operation. Till 2 days back , it was working fine so we were able to delete multiple records from Cosmos DB. But now we are getting a weird error/exception each time we try to delete even a single record. As of now, the no. of records is around 2.3 millions in the container in which we are trying to perform deletion. We have validated multiple times that we are passing correct data to bulk delete API (uniqueId, PartitionKey & Operation Type - Delete ) even then we are facing above issue . Same Bulk delete API is working fine for other containers having much lesser amount of data .
To Reproduce
Steps to reproduce the behavior:
1.
Expected behavior
We should be able to perform deletion sucessfully no matter how many records we have in the container.
Screenshots
Added screenshot to help explain our problem.
Additional context
As part of a validation check, we tried to delete records for other containers in our DEV & SIT env and the records got deleted successfully. We did an analysis for the above issue and couldn’t find much on internet also except the below links.
#18682
azure-sdk-for-js/sdk/cosmosdb/cosmos/src/client/Item/Items.ts
Line 463 in 3cfbb8b
Using above links, we can see the code written in Azure Cosmos Node JS library and the exception is being thrown from the library itself based on some internal min-max range for partition key. From our side, we cannot do much as of now to debug this further so raising a ticket here for further help.
The text was updated successfully, but these errors were encountered: