uber-cadence框架是否对工作流生命周期中接收到的信号数量施加了限制？

Question

Uber的Cadence表示，一个工作流不能期望在工作流的生命周期内运行超过10万个活动。https://cadenceworkflow.io/docs/concepts/workflows/#child-workflow

单个工作流的大小有限。例如，它不能执行100 k活动。子工作流可用于将问题划分为较小的块。每一个执行1000个活动的有1000个子的父母是100万个已执行的活动。

我在想，是不是因为接收到了许多信号而对#的状态变化施加了一些类似的限制呢？

在我的用例中，我有一个长时间运行的工作流(几个月到几年)，每个工作流都会跟踪用户在游戏系统中的活动。每个用户工作流接收的信号总数每隔几天就会超过100 k，从而导致超过100 k的工作流状态变化。

问题是，在我的业务逻辑中，每个信号不一定会调用活动调用，因此每个工作流调用的活动总数可以保持在较低的水平。(例如，100个活动电话总数，而接收到的信号超过100 K)

在此场景中，

1. 工作流会抛出任何错误，因为工作流的内部历史记录太长，无法跟踪接收到的100k+信号，尽管文档？

中每个指南只有数百个活动调用。

我不清楚cadence引用100 k活动限制是否仅适用于活动调用的总数或所有状态更改(活动、信号、查询等)的总数。

Answer 1

是否对工作流生命周期中接收到的信号数量施加限制？

是。默认情况下是10K。见MaximumSignalsPerExecution in https://pkg.go.dev/github.com/uber/cadence@v0.23.1/common/dynamicconfig#Key

更准确地说，这个10K信号限制是从这个commit的0.16版本开始的：https://github.com/uber/cadence/commit/0993f6ebb0ceda610f9e47fe8569db50485b0e18

小于0.16的版本没有任何限制。

当向工作流发送超过限制数量的信号时，Cadence将拒绝信号请求。

每个用户工作流将接收的信号总数每隔几天可以超过100 k，这导致超过100 k的工作流状态changes.In --在这种情况下，can工作流是否会抛出任何错误，因为工作流的内部历史太长，无法跟踪接收到的100k+信号，尽管在文档中每个指南只有数百个活动调用？

默认情况下，韵律要求历史记录小于200 K。

见HistoryCountLimitError in https://pkg.go.dev/github.com/uber/cadence@v0.23.1/common/dynamicconfig#Key

当历史超过此限制时，Cadence将立即终止工作流。但是，您可以调整配置，然后重新设置工作流。