Node.js 区分dynamodb TransactionCanceledException的方法

我有一个使用DynamoDB作为数据库的带有事务的api。我将得到两种例外情况。一种是由于不满足条件时的条件检查失败异常造成的。错误对象如下所示：

{
    "message": "Transaction cancelled, please refer cancellation reasons for specific reasons [None, ConditionalCheckFailed]",
    "code": "TransactionCanceledException",
    "time": "2020-01-22T05:46:32.756Z",
    "requestId": "UG14A08TDB6Q5CADF0NH9JQAB3VV4KQNSO5AEMVJF66Q9ASUAAJG",
    "statusCode": 400,
    "retryable": false,
    "retryDelay": 32.837614849025734
}

另一种情况是，当我在同一个api上进行负载测试时，我将得到TransactionConflict异常

{
    "message": "Transaction cancelled, please refer cancellation reasons for specific reasons [None, TransactionConflict]",
    "code": "TransactionCanceledException",
    "time": "2020-01-22T05:54:40.940Z",
    "requestId": "87MHRV37F3G3EUUF629AKICARBVV4KQNSO5AEMVJF66Q9ASUAAJG",
    "statusCode": 400,
    "retryable": false,
    "retryDelay": 31.786748424710908
}

由于TransactionConflict异常，我想在出现错误时重试该事务。但我不确定如何使用此错误信息有条件地重试该事务。因为消息部分是唯一告诉我错误确切原因的键，而不是错误代码本身

---

我不认为比较消息是有条件地处理错误的好方法

据我所知，DynamoDB的所有400个错误都是

不可重试的

。 这意味着接收API请求的方式存在问题，它不正确，因此出现400错误

因此，在您的情况下，我建议修复该问题，然后在收到可重试的异常时添加重试。更多参考：

只能重试500个错误

我不认为比较消息是有条件地处理错误的好方法

我完全同意，但是：

• AWS在不改变API方面做得非常好，所以您可能对这种方法没有意见，并且
• 他们似乎没有给你任何选择

---

我建议，一种安全的方法是字符串匹配消息，但如果您得到的

TransactionCanceledException

消息与任何预期字符串都不匹配，也可以抛出您自己的异常——不要简单地测试它是否等于/不等于一个可能的字符串，而是测试所有已知/相关值，如果没有匹配已知模式，则停止并着火。这消除了对错误文本进行意外更改而导致代码行为异常的风险。

这并不完全正确，因为OP指的是更高级别的重试，其中应用程序代码表示“嗯，交易冲突？这可能是暂时的，因此我想创建一个新的、相同的请求，然后再次尝试相同的操作。“它有可能随后成功，因此不是文档中讨论的“重试”。在再次提交请求之前，您必须解决应用程序中的问题“在这里不适用，因为请求没有错，它只是在当时与另一个试图进行冲突事务的请求发生冲突。我对这个问题的研究似乎也反映了这种情绪。异常本身除了它被实例化时使用的注释字符串之外，几乎没有什么有用的信息。这是AWS工具的一个完全令人发狂的特性，但我认为你是对的，这是不可能改变的。因此，现在如果你想编写一个智能应用程序，你需要解析字符串中的一个“数组”错误，并尝试将它们映射回你的事务包含的多个操作。有趣。