service/dynamodb: No way to get CancellationReasons from a TransactionCanceledException?

[guregu]

Version of AWS SDK for Go?

v1.15.86

Version of Go (go version)?

go version go1.10.3 darwin/amd64

What issue did you see?

When I try to execute a TransactWriteItems with conditions in the items that fail, there seems to be no way to get the CancellationReasons from the error that is returned. This also means that I can't retrieve the original data of the failing items when I set ReturnValuesOnConditionCheckFailure to be ReturnValuesOnConditionCheckFailureAllOld.

Steps to reproduce

1. Create a TransactWriteItems request with a few puts.
2. Include a failing condition in one of the puts.
3. Something like this error is returned (this is output from go-spew):

(*awserr.requestError)(0xc42014a1e0)({
 awsError: (*awserr.baseError)(0xc4202f61c0)({
  code: (string) (len=28) "TransactionCanceledException",
  message: (string) (len=108) "Transaction cancelled, please refer cancellation reasons for specific reasons [ConditionalCheckFailed, None]",
  errs: ([]error) <nil>
 }),
 statusCode: (int) 400,
 requestID: (string) (len=52) "[omitted]"
})

As far as I can tell, there's no way to get the CancellationReasons from this (which are present in the response JSON when I enable verbose logging). Apologies if I'm simply overlooking the correct method.

[diehlaws]

Thank you for reaching out about this @guregu. While the CancellationReason structure is present in the API model for DynamoDB, the AWS SDK for Java is the only SDK that currently supports unmarshalling this structure. I've marked this issue as a Feature Request, and will bring it up in our next sprint.

[ronnylt]

Any update on this? Thanks!

[jasdel]

Hi @ronnylt, the support for unmarshaling API errors is still an outstanding item on our backlog. In the meantime we do have a workaround example, https://github.com/aws/aws-sdk-go/blob/master/example/service/dynamodb/transactWriteItems that will show how you can workaround this issue.

[ccbrown]

@jasdel Is there some sort of blocker for this or is it just a matter of someone putting in the effort? If it's the latter, I'll be glad to put in a PR. But considering you went through the effort of putting together that example rather than a PR, I'm guessing there's some other issue?

[nc-wittj]

Has this been fixed in v1.28.0? I haven't gotten the chance to check, but it seems to be the case looking at the SDK Features release notes.

[skotambkar]

This has been fixed in v1.28.0 . I will go ahead and close this issue.