Go Lambda 的 AWS Step Function 错误处理

Question

我找不到如何根据 Go 处理程序返回的错误在 Step 函数中定义错误条件匹配器的详细说明。

这handler是一个标准的 Go 函数，error如果从上游服务获取 503 则返回：

func HandleHotelBookingRequest(ctx context.Context, booking HotelBookingRequest) (
    confirmation HotelBookingResponse, err error) {
    
    ...
        if statusCode == http.StatusServiceUnavailable {
            err = errors.New("TransientError")
        } else {

我可以控制函数返回的内容以及它如何格式化字符串；我找不到任何关于在这里使用什么的真实信息（或者在一个Catch子句中），所以这与上面的内容相匹配：

      "Retry": [
        {
          "ErrorEquals": [
            "TransientError"
          ],
          "BackoffRate": 1,
          "IntervalSeconds": 1,
          "MaxAttempts": 3,
          "Comment": "Retry for Transient Errors (503)"
        }
      ]

当我在控制台中测试 Lambda 时，当上游返回 503 时，我得到的结果（如预期）：

{
  "errorMessage": "TransientError",
  "errorType": "errorString"
}

我有一个明显的印象（但不太确定如何验证这一点），如果我更改为：

          "ErrorEquals": [
            "errorString"
          ],

有效Retry（至少，查看 CloudWatch 日志，我可以看到transient error正在记录 s，但 Step 函数最终成功）。

我找不到太多这方面的文档，但是：

1. 是否可以匹配实际的错误消息（我看到API网关允许使用正则表达式来做到这一点）；
2. 如果这是不可能的，我应该返回不同的“错误类型”，而不是error

提前致谢！

Answer 1

终于解开了谜题；最后，它很简单，并且与 JavaScript 方法相当相同（（a）给了我提示，（b）在示例中被广泛记录）；然而，由于我无法在任何地方找到特定于 Go 的答案（在 AWS - 广泛的、良好的、详细的 - 文档中，Google，这里），我将其发布在这里以供将来参考。

TL;DR - 定义您自己的接口实现error并返回该类型的对象，而不是 bog-standard fmt.Error()，然后在子句中使用类型名称ErrorEquals。

本要点中显示了一个非常基本的示例实现。

为了测试这一点，我创建了一个ErrorStateMachine（相同要点中的 JSON 定义）并根据类型选择了不同的捕手ErrorEquals：

        {
          "ErrorEquals": [
            "HandlerError"
          ],
          "Next": "Handler Error"
        }

使用不同的输入测试阶跃函数Outcome会导致选择不同的路径。

我猜让我困惑的是，当谈到 Go 时，我是一个相对初学者，我没有意识到这是该方法返回的接口errorString的实际类型，该类型在内部使用：errorerrors.New()fmt.Errorf()

        {
          "ErrorEquals": [
            "HandlerError"
          ],
          "Next": "Handler Error"
        }

我天真地认为这只是 AWS 命名的东西。

一个有趣的变化（这并不理想）是实际的错误消息被“包装”在 Step 函数输出中，并且在后续步骤中解析可能有点麻烦：

// in errors/errors.go

// errorString is a trivial implementation of error.
type errorString struct {
    s string
}

将实际的错误消息（由 生成）直接发送到现场肯定会对开发人员更加友好。Error()Cause

希望其他人发现这很有用，而不必像我一样浪费时间。