For ConditionCheckFailedException, its now possible to have the exception include the content of the conflicting item in the same roundtrip, by setting ReturnValuesOnConditionCheckFailure flag in the request)
The library should either turn that on unconditionally (there is no RU charge impact, though obviously the response will be larger)
But, really, any API that's annotated as potentially triggering a Precondition.CheckFailed, the option should be available to include it in the response
(NOTE the AWS SDK's exception type has long been plumbed for holding the content in question - the new bit is the fact that a DDB server will now include it in the response for single Item APIs as TransactWriteItems has done for some time).
It's unclear to me whether a SDK update will be necessary (my money is on no though)
For
ConditionCheckFailedException, its now possible to have the exception include the content of the conflicting item in the same roundtrip, by settingReturnValuesOnConditionCheckFailureflag in the request)The library should either turn that on unconditionally (there is no RU charge impact, though obviously the response will be larger)
TransactWriteItems,PutItemAsyncandUpdateItemAsynchttps://github.com/jet/equinox/blob/8d44e38eeccbc3bf9ccd1d28892d14a50a36a66a/src/Equinox.DynamoStore/DynamoStore.fs#L575-L577Precondition.CheckFailed, the option should be available to include it in the response(NOTE the AWS SDK's exception type has long been plumbed for holding the content in question - the new bit is the fact that a DDB server will now include it in the response for single Item APIs as
TransactWriteItemshas done for some time).It's unclear to me whether a SDK update will be necessary (my money is on no though)