Stubber with "dynamodb_client.transact_write_items" is unable to produce error response for tests

[brysontyrrell]

Describe the bug

dynamodb_client.transact_write_items now returns "CancellationReasons" in the error response.

Attempting to write a test around this is not possible with the Stubber.

Here is the error response for a conditional check failure using a transaction with boto3:

{
    "Error": {
        "Message": "Transaction cancelled, please refer cancellation reasons for specific reasons [ConditionalCheckFailed]",
        "Code": "TransactionCanceledException"
    },
    "ResponseMetadata": {...},
    "Message": "Transaction cancelled, please refer cancellation reasons for specific reasons [ConditionalCheckFailed]",
    "CancellationReasons": [
        {
            "Code": "ConditionalCheckFailed",
            "Message": "The conditional request failed"
        }
    ]
}

CancellationReasons is a top level key instead of residing inside of the Error (also, strangely, Message is duplicated here as well).

The Stubber only allows adding metadata to the error or response. Both examples of these Stubber generated outputs are shown below (captured during pytest runs).

stubber.add_client_error(
        "transact_write_items",
        service_error_code="TransactionCanceledException",
        service_message="Transaction cancelled, please refer cancellation reasons for specific reasons [None, ConditionalCheckFailed]",
        response_meta={"CancellationReasons": [{"Code": "ConditionalCheckFailed"}]},
       # service_error_meta={...},
        http_status_code=400,
        expected_params=expected_params,
    )

{
    "ResponseMetadata": {
        "HTTPStatusCode": 400,
        "CancellationReasons": [
            {
                "Code": "ConditionalCheckFailed"
            }
        ]
    },
    "Error": {
        "Message": "Transaction cancelled, please refer cancellation reasons for specific reasons [ConditionalCheckFailed]",
        "Code": "TransactionCanceledException"
    }
}

{
    "ResponseMetadata": {
        "HTTPStatusCode": 400
    },
    "Error": {
        "Message": "Transaction cancelled, please refer cancellation reasons for specific reasons [ConditionalCheckFailed]",
        "Code": "TransactionCanceledException",
        "CancellationReasons": [
            {
                "Code": "ConditionalCheckFailed"
            }
        ]
    }
}

Expected behavior

This is the only operation in boto3 I've come across that breaks with the Stubber.

It is not clear to me if the Stubber needs to be updated to accomondate how transact_write_items returns "CancellationReasons", or if the implementation of returning "CancellationReasons" has a bug and those keys are supposed to be inside the Error.

[kdaily]

Hi @brysontyrrell,

Sorry to hear you're having an issue. I'm looking into this. I'm wondering for your statement:

dynamodb_client.transact_write_items now returns "CancellationReasons" in the error response.

Do you mean to say that this did not occur previously? This structure with the cancellation reasons outside of the error has been in the API model for three years.

https://github.com/boto/botocore/blob/354e9cb22017112a6f72fb20c36b133c9f346002/botocore/data/dynamodb/2012-08-10/service-2.json#L5380-L5391

And yes, per the model the message is duplicated inside the reasons too:

https://github.com/boto/botocore/blob/354e9cb22017112a6f72fb20c36b133c9f346002/botocore/data/dynamodb/2012-08-10/service-2.json#L1530-L1553

I'll need to do some more research to determine next steps. Thanks for your patience!

[brysontyrrell]

Hi @kdaily,

It might have been in the model but it wasn't being returned as a part of the SDK response. We had a ticket opened back in Nov 2020 about that. #2657 Just recently when coming back to transactions I saw that it was now being returned.

[kdaily]

Hi @brysontyrrell, it does look like we can close out #2657!

Also, a PR was just posted (boto/botocore#2636) to address this feature gap.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.