Corda4.0更新修改Flow的CorDapp后无法流转APPROVED状态至CANCELLED如何处理

问题根因定位 #

你遇到的The Initiator of CollectSignaturesFlow must pass in exactly the sessions required to sign the transaction.报错，本质是CollectSignaturesFlow接收的会话列表对应的签名公钥，和当前交易要求的必须签名公钥集合不匹配导致的，确认会话逻辑正确的前提下，大概率是Flow版本升级未做序列化兼容、或者交易签名要求的逻辑修改没有兼容旧状态导致。

修复方案 #

基础校验项 #

• 对比新旧版本Flow3代码，确认是否修改了@InitiatingFlow注解的participants属性，或者在交易构建逻辑中新增/减少了必须签名方，比如误将Notary加入需要收集签名的列表、或者漏加Provider/Consumer1的签名要求
• 调试时打印当前交易的requiredSigningKeys集合，以及传入CollectSignaturesFlow的会话对应的公钥集合，确认两者完全匹配，无多传、少传、公钥不匹配的情况

兼容升级方案 #

• 给修改后的Flow3显式添加@FlowVersion注解，版本号比旧版本大1即可；如果调整了Flow的构造函数参数，需要新增兼容旧参数的构造函数，标注@DeprecatedConstructor注解，内部转发调用新构造函数，保证节点数据库中存储的旧序列化Flow实例可以正常反序列化
• 如果修改了Flow3的签名收集逻辑，需要添加分支判断：当输入的状态是旧版本APPROVED状态时，走旧的签名收集逻辑，新生成的状态走新逻辑，避免旧状态执行新逻辑时签名要求不匹配
• 不要修改已发布的状态类结构，如果已经修改，需要给状态类添加显式序列化ID，或者在节点的serialization-white-list.txt中添加状态类全限定名，保证旧状态实例可以被新版本CorDapp正常反序列化

临时应急方案 #

如果需要快速处理已卡住的旧流程，可以临时开发一个Flow3LegacyCompat兼容Flow，逻辑完全对齐旧版本Flow3，仅实现旧APPROVED状态到CANCELLED状态的流转，待所有旧流程处理完毕后再下线该兼容Flow即可。dev模式下如果是测试数据可以直接清空节点的Flow checkpoint目录快速重置，生产环境禁止该操作。

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