azure-sdk-for-js: Unique Key Policy is not being enforced
- package: @azure/cosmos
- version: ^3.6.2
- Linux:
- nodejs
- version: ^8.5.4
- Google Chrome
- version/name: 88.0.4324.190 (Official Build) (64-bit)
- typescript
- version: ^3.7.3
Describe the bug The container I have created is not following the unique key policy that I have set. I suspect this is due to the fact that both items are being persisted at the exact same time.
To Reproduce Steps to reproduce the behavior:
- Insert two items that have the exact same _ts, subject and seq value.
- Both items persist in the database.
Expected behavior I expect one or both of these documents to get rejected from persistence.
Screenshots
Additional context Here is the code I used to create the container and set the unique key policy:
await db.containers.createIfNotExists({
id: eventstore,
partitionKey: { paths: ["/subject"] },
uniqueKeyPolicy: {
uniqueKeys: [
{ paths: ["/seq"] }
]
}
})
I am also using a stored procedure to insert items into this database:
function bulkInsertItems(items) {
var container = getContext().getCollection();
var containerLink = container.getSelfLink();
// Validate input
if (!items) throw new Error("The array is undefined or null.");
// End if there are no items
if (items.length == 0) {
getContext().getResponse().setBody(0);
}
items.map(item => {
var isAccepted = container.createDocument(containerLink, item);
// If the item fails to persist, throw an error and CosmosDB will handle rolling back
if (!isAccepted) {
throw new Error("Unable to create item");
}
})
getContext().getResponse().setBody(items.length);
}
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 18 (10 by maintainers)
Let me try to recreate this on my end
Sounds good, thanks for the info. We’ve had a few asks like I said for Transactional batch so I can see that coming soon. I’m still planning to find time to verify I can reproduce this and would then hand it to the backend team.
Hey @donaldduy-lb, taking a look at this now