We are bothered by the fact that Cosmos DB lease lost exception is an ERROR in our logs

[ericleigh007]

I don't believe that, if this error is handled/expected, that it should show up in my logs as an error.
At worst, this should be a warning, if it is sort of unexpected, but has no follow-on impact.

What appears to be happening here is that the lease owners are using OC in order to de-duplicate their efforts and access to the lease container, but that a 412 might be

Response status code does not indicate success: PreconditionFailed (412); Substatus: 0; ActivityId: ; Reason: (24 lease token was taken over by owner '6ecdb655-ca51-43e3-b367-30fbb47c63e1');

No call stack is available.

[hiroshitashir]

+1 with this issue.

Additional message says, "This is expected during scaling and briefly during initialization". I assume Azure Function has the ownership to the lease container. Whenever Azure function initializes or scales, a new instance of Azure function gains the ownership, and this exception is triggered from CosmosDB.

This exception should probably be caught in Azure Function and suppressed since it knows it's initializing or scaling.

However, I just want to check if throwing this exception in CosmosDB is absolutely necessary.

[ericleigh007]

No thoughts, guys?

BTW, not on this project any longer, but if I were to return, it would be great to have an update that no longer has this problem, or as indicated, this was demoted to a warning?

Thanks!