在AWS步骤功能中管理错误流 [英] Managing error flow in AWS step-functions

查看:86
本文介绍了在AWS步骤功能中管理错误流的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个Lambda函数的AWS步进函数/状态机,该函数主要用Javascript编写(尽管其中一个是用Java编写的),并且我想更好地管理错误处理.

I have an AWS step-function/state-machine of Lambda functions written primarily in Javascript (although one is in Java) and I'd like to manage the error processing better.

我完全可以将错误条件捕获到 然后转发到流程中的另一个状态.因此,例如,状态机中的以下状态定义将执行传递到NotifyOfError状态,在该状态下,我可以通过电子邮件和短信适当地发送有关错误状态的信息.

I have no problem with having an error condition being caught and then forwarded to another state in the flow. So for instance, the following state definition in my state machine passes execution to the NotifyOfError state where I am able to email and sms appropriately about the error state.

Closure:
  Type: Task
  Resource: >-
    arn:aws:lambda:#{AWS::Region}:#{AWS::AccountId}:function:xxx-services-${opt:stage}-transportClosure
  Next: WaitForCloudWatch
  Catch:
    - ErrorEquals:
        - "States.ALL"
      ResultPath: "$.error-info"
      Next: NotifyOfError

但是,我希望将一些错误以不同的方式处理,而不是将所有错误都置于这种状态.因此,起初我认为,如果我使用给定的名称"抛出了Javascript/Node错误,那么该名称将成为我可以在 ErrorEquals 配置中使用的名称.示例:

However, rather than hand ALL errors to this one state there are a few errors I'd like handle differently. So at first I thought that if I threw a Javascript/Node error with a given "name" then that name would be something I could branch off of in the ErrorEquals configuration. Example:

 catch(e) {
      if (e.message.indexOf('something') !== -1) {
           e.name = "SomethingError";
               throw e;
      }

,但很快意识到,该名称仅在步进功能的Cause部分之前,而不是分支的内容.然后,我尝试像这样扩展基本Error类:

but soon realized that name was only being prepended to the Cause portion of the step-function and not something that would branch. I then tried extending the base Error class like so:

export default class UndefinedAssignment extends Error {
  constructor(e: Error) {
    super(e.message);
    this.stack = e.stack;
  }
}

但是抛出此错误实际上并没有执行任何操作,这意味着当它出现在步进功能"中时,错误的类型仍然仅为错误":

but throwing this error actually did nothing, meaning that by the time it showed up in the Step Function the Error's type was still just "Error":

"error-info": {
    "Error": "Error",
    "Cause": "{\"errorMessage\":\"Error: the message",\"errorType\":\"Error\",\"stackTrace\":[\"db.set.catch.e (/var/task/lib/prepWorker/Handler.js:247:23)\",\"process._tickDomainCallback (internal/process/next_tick.js:135:7)\"]}"
}

因此,我仍然不清楚如何在step函数中如何区分Node中源自 branchable 的错误.

So I'm still unclear how I can distinguish errors sourced in Node that are branchable within the step function.

注意:对于Java,看来它确实正确拾取了错误类(尽管我在Java方面所做的测试要少得多)

Note: with Java, it appears it does pickup the error class correctly (although I've done far less testing on the Java side)

推荐答案

这是我获取步骤函数"以自定义错误和消息作为其ErrorCause报告的方式.请注意,我正在将Node.js 8.10 Lambda运行时与asynctry/catch一起使用.

Here's how I get Step Functions to report a custom error and message as its Error and Cause. Note I'm using the Node.js 8.10 Lambda runtime with async and try/catch.

exports.handler = async (event) => {
  function GenericError(name, message) {
    this.name = name;
    this.message = message;
  }
  GenericError.prototype = new Error();
  try {
    // my implementation which might throw an error
    // ...
  }
  catch (e) {
    console.log(e);
    let error = new GenericError('CustomError', 'my message');
    throw error;
  }
};

为简单起见,这里我忽略了catch(e)中的错误对象.如果需要,您也可以将其stack馈入GenericError.

Note for simplicity I'm ignoring the error object from catch(e) here. You could also feed its stack into the GenericError if wanted.

此lambda函数返回:

This lambda function returns:

{
  "errorMessage": "my message",
  "errorType": "CustomError",
  "stackTrace": [
    "exports.handler (/var/task/index.js:33:28)"
  ]
}

Step Functions将其转换为:

Step Functions turns this into:

{
  "error": "CustomError",
  "cause": {
    "errorMessage": "my message",
    "errorType": "CustomError",
    "stackTrace": [
      "exports.handler (/var/task/index.js:33:28)"
    ]
  }
}

在其LambdaFunctionFailed事件历史记录中,并最终再次将其转换为该状态输出(取决于我们的ResultPath-这里没有任何内容):

in its LambdaFunctionFailed event history, and ultimately converts it again into this state output (depending on our ResultPath - here without any):

{
  "Error": "CustomError",
  "Cause": "{\"errorMessage\":\"my message\",\"errorType\":\"CustomError\",\"stackTrace\":[\"exports.handler (/var/task/index.js:33:28)\"]}"
}

这篇关于在AWS步骤功能中管理错误流的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆