Skip to content
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

Cosmos Db save call is failing intermittently with "PreConditionFail" #328

Open
Karthickramk opened this issue Mar 30, 2020 · 5 comments
Open

Comments

@Karthickramk
Copy link

Describe the bug
Cosmos Db save call is failing intermittently with "PreConditionFail". Even though there is no other call is invoked for that particular document at that particular time. We have a retry for this exception. During retry, we reload the data again from database and do the operation. But still we see the same error.
I am using 2.6.6 SDK.

To Reproduce
There is no concrete reproducing step as this very intermittent issue.

Expected behavior
The save call should be success.

Actual behavior
Db call fails with "PreConditionFail"

Environment summary
SDK Version:2.6.6
Java JDK version:openjdk 11.0.4.0.101 2019-10-15 LTS
OS Version (e.g. Windows, Linux, MacOSX) Azure(AKS)

Additional context

@kushagraThapar
Copy link
Member

@Karthickramk - "PreConditionFail" means the call is failing because of etag mismatch.
Seems like the etag you have locally on the document is different from what is stored in the database.
Please check on this etag field.

@imk13
Copy link

imk13 commented Jul 14, 2021

+1

@colgreen
Copy link

colgreen commented Jul 29, 2021

We are seeing this too, and have confirmed that the eTag property is the latest eTag using cosmos DB explorer. Seems like a bug in cosmos DB right now.

@manisrivastav
Copy link

manisrivastav commented Nov 18, 2021

@kushagraThapar we are having similar situation where, we are trying to replace the doc, we have retry logic by reading the latest but intermittently failing for some requests. Unpredictable and not reproducible in local.

JS SDK - @azure/cosmos": "3.6.2",

@v-dhampton
Copy link

v-dhampton commented Dec 11, 2021

This may be due to the Default Consistency level selected for your server which is likely Session. If a document read occurs within a couple milliseconds of document replacement from a different context, you may not receive the latest data.

You can read more about this here with more information here. The only guaranteed latest data consistency model is Strong but you probably don't want to switch.

However, this may not actually be your problem and you may have a real concurrency issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants