调试流程时，我遇到了严重的生产力问题。我现在只能假设是因为我缺乏知识;特别有效的流程调试技术。当我有一个需要“等待”消耗特定状态的流时，就会出现问题。似乎发生的是等待流程开始并等待指定状态的消耗，但尽管实现为具有相关回调的监听未来（此时我只是使用从'WhenConsumed'返回的未来的getOrThrow） ，流程只是挂起，我在控制台窗口中看到数百个Artemis发送/写入消息。如果我停止调试会话，删除节点构建目录，重新部署节点并重新启动流程重新启动，我可以返回到故障点。但是，如果我只是停止并从节点分离调试器并尝试运行调用测试（通过RPC调用流），似乎什么也没发生。这几乎就像流代码（此时可能不正确）导致StateMachine /消息传递层陷入某种状态循环，只有通过擦除节点构建目录并重新部署才能解决。只需重新启动节点，就会导致流程根本不再执行。这是一个真正的生产力杀手，所以我正在写这个问题，希望和假设我错过了一个明显的技巧，如何有效地测试/调试流程，避免反复重新部署节点。 如果有人可以解释如何有效地调试流程，那将是很好的;尤其是依赖于Vault更新的流，因此等待valut更新事件。我考虑过使用子流程，但这最终会（我相信？）不会产生所需的功能;即，当节点消耗所识别的状态时触发流。或许它会？也许这个问题是由于没有使用subFlow ???无论如何，我期待你的想法!!
答案 0 :(得分：2)
不确定您的具体用例。但总的来说， 在物理运行节点之前，我会尽可能多地进行单元测试，看看流是否有效。 Corda提供三个级别的单元测试：交易/分类账DSL，模拟网络和驱动程序DSL。因此，如果做得好，流程中的大多数（如果不是全部）错误都应该在运行时解决。实际的运行节点主要是揭示配置问题。