DynamoDB ConditionalCheckFailedException - obtaining the item content that failed the test

Question

I'm using precondition expressions on PutItem and UpdateItem requests.

Is there a way to achieve either or both of the following:

1. not throw an exception - this is not an exceptional situation, it's an anticipated condition; as with validation of external inputs, I would like to be able to inspect the result without there being a throw and a catch - is there a way to achieve that?

2. given the server has just read the data in order to determine the check failed, is it possible to have it return it, given the RCUs have already been paid and the general pattern is that the before/after can be included as part of the roundtrip? Or is this a truly hard-baked service-side limitation? Would love to see a link to something authoritative as any docs I've traversed are silent on the matter...

(I'm using a current version of the .NET SDK AWSSDK.DynamoDBv2 NuGet package.)

Answer 1

You can see the low-level wire activity documented at https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_PutItem.html which show a 400 response status code if the conditional check fails. At this time there’s no more knowledge to be gained on the failed call without a second call.

Answer 2

I believe I've just found (but no yet tested) the answer... The Put (and Update) operation in TransactWriteItems has a ReturnValuesOnConditionCheckFailure. Unless there is a truly major overhead to that, that's my answer...

---

Looks like the way you extract the item is still sadly by extracting it out of the exception in this sort of manner:

try let! response = client.TransactWriteItemsAsync(req, ct) |> Async.AwaitTaskCorrect
with :? TransactionCanceledException as e -> e.CancellationReasons.[0].Item

The other key difference between a TransactWriteItems vs single PutItem / UpdateItem calls are that you can't obtain the (original or) updated item in the success case.

---

I've yet to validate this works correctly end to end at the present time - the key shortcoming is that the Request Charge Units levied for TransactWriteItems are twice that incurred for individual PutItem/UpdateItem/DeleteItem requests. Thus while for transactional correctness being able to extract the conflicting item may be useful, it's definitely not applicable as a general technique unless you happen to require the atomicity.

Excellent costing guide article.