Throw exception when asking for FirstWrite OCC without ETag

[amolenk]

Describe the proposal

Currently, the SDK allows you to make the following call:

await daprClient.SaveStateAsync<Foo>(
    "storename",
    "key",
    new Foo(),
    new StateOptions
    {
        Concurrency = ConcurrencyMode.FirstWrite
    });

The problem with the call is that we're asking Dapr to do something impossible. FirstWrite OCC will only work if we send an ETag along with the request. SaveStateAsync will never send the ETag, for that you need to call TrySaveStateAsync.

The call will succeed but it won't use FirstWrite OCC. There are other situations where you can give Dapr state management a command/hint that cannot be fulfilled by the underlying state store, such as asking for strong consistency if the data store doesn't support it. However, the FirstWrite issue can be caught early at the SDK level.

I propose throwing an exception with a clear message explaining that you need ETag/TrySaveState to use FirstWrite.

[rynowak]

Thanks for the report. Agree that this doesn't make sense.

You said that the call succeeds - so in this case it's also accepted by the state store? I want to bubble this up to the Dapr API/runtime level as well. I think it's fine if the .NET SDK is as-strict with validation as the Dapr API, but it's not a good thing if we're more strict.

[rynowak]

/cc @mukundansundar @yaron2

[amolenk]

Yes, it's accepted by the state store. As long as the request doesn't contain an ETag, Dapr will always use last-write-wins.

The OCC mechanism also doesn't make any distinction between a blank and a missing ETag. This causes problems when inserting new data. I've added a comment to this existing issue: dapr/dapr#2320

I've also added a proposal to use HTTP 409 Conflict when ETags don't match instead of a generic HTTP 500. That way it will be much easier to distinguish ETag mismatches from other errors. dapr/dapr#2619

[rynowak]

Thanks, that saves me the legwork 👍