假设我们需要在用户完成他/她的购物车之后生成订单。
这是我们生成订单的步骤：
为此，我们只需创建一个节奏工作流，为每个步骤调用一个活动。
问题1：如果用户再次打开购物车或刷新页面，客户端如何检测到该购物车的订单正在创建中？ （注意：假设我们的工作流还没有被worker执行）
我对问题1的解决方案：在运行工作流之前创建订单并将其状态更改为pending，因此对于下一个请求，客户端知道该订单处于待处理状态。但是如果订单创建成功，但启动工作流失败，会发生什么？它不是事务性的（订单创建和工作流程运行）
如果此解决方案也是您的解决方案并且您接受其风险，请告诉我。我是节奏的新手。
问题2：在工作流完成且订单准备好后如何通知客户？
请提供任何解决方案或文章或帮助？
【问题讨论】：
标签： cadence-workflow temporal-workflow uber-cadence
问题 1：有多种解决方案需要考虑：
1.1 在工作流中添加一个步骤，在调用订单微服务之前将订单更改为待处理状态，而不是在工作流之外进行。它将使您免于一致性问题，您可以在工作流中添加重试以确保状态最终一致。
1.2 增加查询方法查询工作流状态，用户/UI可以通过queryWorkflow调用获取工作流状态查看订单状态。
1.3 将状态放入工作流的SearchAttribute，用户/UI可以调用describeWorkflow获取状态
1.4。实现https://github.com/uber/cadence/issues/3729后，可以像1.3那样使用memo代替SearchAttribute
比较：如果您认为订单存储是订单状态的真相来源，1.1是选择，1.2~1.4将使工作流成为真相来源。这实际上取决于您要如何设计系统架构。
如果用户/UI 期望低延迟，1.2 可能不是一个好的选择。因为 QueryCall 可能需要几秒钟才能返回。
1.3~1.4 的性能/速度会更高。它只需要 Cadence 服务器进行数据库调用即可获取工作流状态。
如果您通过 ElasticSearch+Kafka 设置启用了 Advanced visibility，1.3 还有另一个好处——您可以按订单状态搜索/过滤/计数工作流。但是 1.3 的限制是你应该只放置非常小的数据，比如字符串/整数，而不是状态的 blob。
1.4 的好处是您可以放置一个状态块。
为了防止用户多次完成购物车： 启动工作流时，使用与购物车关联的稳定工作流ID。这样您就可以在允许他们完成/结帐购物车之前调用 describeWF。一旦 StartWF 请求被接受，工作流就会持续存在。 如果有活动的工作流程（未失败/完成/超时），则表示购物车处于待处理状态。例如，如果购物车使用 UUID，那么您可以使用该 UUID+前缀来制作工作流ID。 Cadence 保证workflowID uniqueness 因此不会出现为同一个购物车启动两个工作流的竞争条件。如果结帐失败，则用户可以再次提交结帐工作流。
问题 2 ：这取决于“通知”您想要什么。术语通知听起来像异步通知。如果是这种情况，您可以使用另一个活动将通知发送到另一个微服务，或者将 signal 发送到需要通知的另一个工作流。
如果这里指的是同步方式，例如在 WebUI 上显示，那么可以按照我在问题 1 中提到的解决方案中的相同方式解决。
【讨论】：
pending 状态，如果用户刷新页面，它将再次请求完成购物车。