Shopify Flow 中的错误故障排除

创建新工作流时，您可能会遇到一条错误消息，内容为 您已达到允许的 1000 个工作流的上限。若要继续，请删除任何未使用的工作流，然后重试。

Flow 将商店可拥有的工作流数量限制为 1000 个。这包括处于“已激活”和“未激活”状态的工作流。如果您达到此上限并想创建新工作流，则需要删除未使用或未激活的工作流。

如果您的商店在设置此限制之前已有超过 1000 个工作流，那么您的商店可以继续使用超过 1000 个工作流来运营。但是，若要创建新工作流，您的工作流数量必须低于该上限。

在 Flow 应用中执行以下多项操作时，您可能会遇到此错误：

• 创建新工作流
• 复制工作流
• 导入工作流
• 安装模板

激活工作流时，您可能会看到一条警告，提示您的商店有 10 个以上使用同一触发器的活跃工作流。

多个工作流共享同一触发器可能会导致性能问题，因为每次发生触发器事件时，Flow 都必须处理所有关联的工作流。这种扇出机制可能会导致执行时间变长并增加资源使用量。

若要减少单个触发器上的工作流数量，请考虑以下方法：

• 将使用同一触发器的工作流合并为包含多个分支和条件的单个工作流。
• 停用或删除不再需要的工作流。
• 评估某些工作流是否可以改用更具体的触发器。

向工作流添加新操作时，您可能会遇到一条错误消息，内容为 未找到数据：

出现此错误的原因是，许多操作（包括添加产品标签）都需要 Shopify 资源，例如产品。如果该资源不可用，则操作无法运行。通常，工作流可能包含与所需数据相似的数据，但实际上并未提供所需内容。

以下部分介绍了可能导致此错误的常见场景及其解决方法。

问题 1：在需要单个商品时，“获取数据”提供了列表

工作流通常会提供 Shopify 资源列表，但操作只允许使用单个资源。例如，工作流通过 获取产品数据 提供了产品列表，但 添加产品标签 操作需要单个产品。

若要解决此错误，您可以添加 For each 操作来循环访问列表，并为列表中的每个商品调用该操作。此示例说明了该错误以及使用 For each 的解决方法：

问题 2：在需要单个商品时，触发器提供了列表

当操作需要单个资源但触发器提供的是列表时，也可能发生类似错误。例如，将发货订单标记为已发货 需要发货订单，但触发器来自订单，而订单提供的是发货订单列表。

若要解决此错误，与问题 1 一样，您可以添加 For each 操作来循环访问列表，并为列表中的每个项目调用该操作：

或者，您可以使用提供所需资源的其他触发器。例如，您可以使用准备发货的发货订单触发器来代替已创建订单触发器，该触发器可提供单个发货订单。

问题 3：“计划时间”触发器未提供数据

计划时间 触发器不提供 Shopify 资源数据。如果您尝试在该触发器后连接需要 Shopify 资源的操作，则会遇到该错误。

若要解决此错误，请添加可提供所需数据的操作，例如 获取产品数据。如问题 1 中所述，您还必须添加 For each 操作以循环访问“获取数据”操作返回的任何列表。

问题 4：应用触发器未提供数据

与问题 3 类似，应用创建的某些触发器不提供所需的 Shopify 资源数据。例如，“评论已创建”触发器可能会提供电子邮件地址，但不会提供客户对象，而许多操作（例如 添加客户标签）都需要客户对象。

若要解决此错误，您或许可以使用“获取数据”操作来提取所需的 Shopify 资源。例如，您可以使用 获取客户数据，通过触发器提供的电子邮件地址来获取客户对象。与其他问题一样，您还必须添加 For each 操作以循环访问“获取数据”操作返回的任何列表。

如果“获取数据”不可用，那么您可能需要联系应用开发者，询问他们是否可以修改其触发器以提供所需数据。

向工作流中添加新的等待步骤时，您可能会遇到一条错误消息，内容为 工作流的等待步骤必须为 40 个或更少。

Flow 将工作流中允许的等待步骤数量限制为 40 个。如果遇到此错误，则表示您已超出此限制。若要解决此问题，请删除工作流中其他位置的等待步骤。

如果您在此限制推出之前已有包含超过 40 个等待步骤的工作流，则您的工作流将继续按预期运行。但是，若要添加其他等待步骤，您必须先删除现有步骤，以确保不超过数量上限。

此外，所有等待步骤的总等待时间不能超过 90 天。

在工作流中编辑条件内的配置字段值时，您可能会遇到一条错误消息，内容为 配置字段值必须小于 50kB。

Flow 将配置字段值的大小限制为 50kB 的数据。当您遇到此错误时，表示您已达到或超出该限制。若要解决此问题，请缩短您要添加到该字段的数据的长度。

如果您已有值为 50kB 或更大的配置字段，那么您的工作流将继续按预期运行。但是，若要对工作流进行更改，您必须修改导致错误的值。

当工作流中的任务尝试在一个区段内查询过多数据时，通常会发生 步骤超时 错误。此错误通常发生在遍历列表的工作流中，尤其是当嵌套列表过大而无法快速处理时。

发生此错误时，触发器或等待步骤将显示为 正在重试。

若要解决此问题，请检查访问列表和嵌套列表的条件，以确认其设置正确。一个常见问题是，某个条件检查的是商店中的所有产品，而不是仅检查订单中的产品。

大多数 Flow 操作都涉及发出 HTTP 调用。偶尔，网络或其他服务器问题可能会导致 HTTP 调用失败，并返回 500 到 599 之间的错误代码。出现一次此错误不成问题，但如果重复出现，则可能表明处理任务的服务器存在问题，而不是步骤的配置方式有问题。

此类错误最常出现在发送 HTTP 请求操作上，但也可能发生在大多数任务上。

工作流完成的总工作量受 API 频率限制的制约，而这些限制部分取决于您的套餐。通常，除非工作流非常复杂或包含无意的设计错误，否则不会达到这些限制。

以下示例描述了可能导致此错误的情况：

• 工作流中的 Liquid 或条件循环访问包含大量数据的列表，例如检查包含 HTML 的元字段值。
• 工作流中的 Liquid 或条件循环访问大型列表，例如在大型商店中循环访问 shop.orders。
• 工作流导致无限循环，即工作流不断创建新的工作流运行。例如，如果工作流使用已添加客户标记触发器并包含添加客户标记操作，则可能会发生这种情况。

如果达到限制，您会收到 GraphQL 受限错误。此错误可能会在其他工作流尝试运行时影响它们，因此，如果发生此错误，请立即解决。

Shopify 操作需要一个或多个资源（例如产品、客户或订单）才能运行。如果所需资源不可用，则操作无法按预期运行。例如，可以在 Shopify 后台中创建没有客户的订单。如果您运行添加客户标记等操作，该操作将失败并显示此错误。

为防止出现此错误，请在操作前添加一个条件以检查资源是否存在。在前面的示例中，如果您想在与添加客户标记相同的工作流中发送内部电子邮件，则可以将电子邮件操作放在可能失败的步骤之前，或使用以下方法之一：

将操作置于并行分支中（即一个步骤分出 2 个或更多分支）：

在操作前添加一个条件以检查客户是否存在。例如，您可以检查 order / customer / id is not empty and exists。

Google Sheets 连接器需要您将 Google 账号关联到 Flow，以获取向工作表写入的权限。如果 Flow 没有向工作表写入的权限，则可能会发生此错误，原因可能是账号已与 Flow 取消关联，或该账号无法访问该工作表。

若要解决此问题，请确保用于连接器的账号可以打开该工作表并具有编辑权限。如果关联了错误的账号，您可以断开其连接并连接新账号。

步骤：

1. 打开现有工作流或创建新工作流。
2. 向工作流添加操作。
3. 选择 Google Sheets 连接器。
4. 点击断开连接，然后点击连接以重新连接正确的 Google 账号。

发送营销电子邮件操作不会向未同意接收营销邮件的客户发送电子邮件，如果工作流尝试这样做，则会永久失败。

若要解决此问题，请在工作流中添加一个条件来检查客户的订阅状态。您可以在发送营销电子邮件前确保客户已同意接收。请按照电子邮件订阅者名单管理中的步骤操作。

此错误表示在工作流能够获取其数据之前，某个资源（例如 customer 或 order）已被删除。这种情况最常发生在等待步骤之后，但如果资源在触发事件发生后很快被删除，那么它也可能发生在触发器上。

此消息表示某个工作流的运行耗时过长。这通常是由于在工作流中使用了大量数据，而 Flow 需要很长时间才能访取这些数据。

这些情况通常是由于深层请求路径遍历了多个项目列表而引起的（例如，请求某个产品所属的所有产品系列中所有产品的全部元字段）：

这也通常与工作流触发器步骤的超时相关。

通过仅使用特定元字段，通常可以改进循环遍历所有元字段的工作流。访问多个嵌套列表（例如某个产品所属的所有产品系列中的所有产品）或特别大的列表（例如包含所有对象的所有元字段的元字段定义）可能是在无意中完成的，选择正确的字段（单个产品或对象上的单个元字段）可以显著提高效率。在其他情况下，使用带查询筛选条件的“获取产品/订单/客户数据”操作可以显著减少使用的对象数量，但仍能访问相关对象。

此消息表示某个工作流的运行正在生成大量数据。这通常是由于设置了会检查多个字段的复杂条件所致，而这些字段通常位于多层列表中。

例如，类似“对于此客户的至少一个标记，对于至少一个订单项目，对于该项目上的至少一个标记”的条件可能会导致执行大量检查，并生成大量数据以显示这些检查的结果：

此消息表示某个工作流的运行由于某些临时问题而反复失败，并且后续重试的成功率不高。当 Shopify 的 Admin API 或合作伙伴的应用遇到大量请求时，通常会发生这种情况。