Step Function编排Redshift ETL流程时Choice状态分支匹配异常

问题1：Redshift集群状态为available时，Choice状态仍进入Default失败分支 #

排查路径 #

• 校验GetStateOfCluster关联Lambda的返回值结构：你当前配置的ResultPath是$.clusterStatus，如果Lambda返回的不是纯字符串状态值，而是嵌套JSON结构（例如返回{"status":"available"}），那么$.clusterStatus实际是对象类型，和StringEquals规则里的字符串available匹配必然失败，会直接走Default分支。
• 校验返回值的格式细节：检查Lambda返回的状态值是否有大小写差异（例如返回Available而非available）、前后多余空格、特殊字符，这类格式问题也会导致字符串匹配失败。
• 直接查看Step Function执行日志：在控制台找到对应执行的IsClusterAvailable状态的输入参数，确认$.clusterStatus字段的实际值，即可快速定位匹配失败的原因。

修复方案 #

• 如果Lambda返回嵌套结构，将Choice规则的变量路径调整为对应层级，例如Lambda返回{"ClusterState":"available"}，就把Variable值改为$.clusterStatus.ClusterState。
• 如果是格式问题，要么修正Lambda返回值为规则匹配的标准字符串，要么使用StringEqualsIgnoreCase、StringTrim等Step Functions内置函数对输入值预处理后再匹配。
• 额外注意你贴出的状态机代码存在语法错误：GetStateOfCluster的Resource字段值为"lambda,，缺少闭合引号，且Resource必须填写Lambda函数的完整ARN，不能直接写lambda，该语法问题也会导致返回值异常。

问题2：删除Default分支后触发状态跳转报错 #

该报错是AWS Step Functions的强制规则导致：所有Choice类型状态必须覆盖所有可能的输入场景，要么所有可能的输入都能命中预设的Choice规则，要么配置Default分支作为兜底跳转逻辑。如果删除Default分支，又出现了无法命中任何规则的输入值，就会抛出找不到下一个执行状态的错误。
官方示例未配置Default是因为示例中的Lambda返回值严格限定为规则覆盖的枚举值，不会出现其他异常状态，如果你无法保证你的Lambda返回值一定属于你预设的4种状态范畴，必须保留Default分支。

修复方案 #

保留Default分支，同时优化Default的处理逻辑：可以将Default分支先指向Wait状态等待一段时间后，跳回GetStateOfCluster重新拉取集群状态，避免偶发的状态查询异常直接导致流水线失败；也可以在Default分支的错误Cause中加入$.clusterStatus的实际值，方便后续排查未覆盖的异常状态。

内容的提问来源于stack exchange，提问作者Adi334