Corda TwoPartyTradeFlow抛出“Failed requirement”异常排查求助

刚重构类似交易流程时踩过这个坑，模糊的Failed requirement.异常确实头疼，给你几个落地的排查方向，一步步来就能定位问题：

1. 先给校验加具体错误提示，直接定位问题点 #

默认的requireThat如果只写通用提示，根本不知道哪项校验挂了。找到TwoPartyTradeFlow.Seller里所有的校验逻辑，给每个校验补充明确的场景描述：

// 原来的模糊写法
requireThat(amount != null, "Failed requirement.");
// 改成带具体场景的提示
requireThat(amount != null, "Seller trade flow requires a non-null transaction amount");
requireThat(amount.getQuantity() > 0, "Transaction amount must be greater than zero");
requireThat(otherParty != null, "Seller must specify a valid counterparty (otherParty)");

修改后重新运行，抛出的异常就会直接告诉你是金额为空、金额为负还是对手方无效，一步到位。

2. 检查API传入的参数合法性 #

• amount参数：确认API传的金额是不是符合Commercial Paper的规则——比如有没有小于CP的最小面额，或者超过了你当前持有的CP总价值？另外要注意类型匹配，比如是不是用了Amount<Issued<CommercialPaper>>而不是普通的数字类型，类型不匹配也会触发隐性校验失败。
• otherParty参数：检查对手方的身份是不是合法的网络节点——比如有没有在网络里注册，X500名称是不是拼写正确？有些流程会校验对手方是不是可信节点，或者是不是属于允许交易的参与者池。

3. 验证从其他流程获取的Commercial Paper状态 #

你提到从另一个流程拿已发行的CP，这里很容易出问题：

• 确认拿到的CP是不是处于可交易状态：比如有没有过期、被质押，或者当前持有者不是你的节点？交易流程第一步通常会校验CP的状态是不是ISSUED且所有权属于发起方。
• 检查CP对象是不是完整：有没有可能获取流程返回了null，或者只拿到了部分字段？比如CP的面额、到期日这些关键字段缺失，也会导致后续校验失败。

4. 查看节点日志找细节 #

如果上面的方法还没解决，去节点的日志目录（默认是logs文件夹）找flow执行的详细日志。节点会记录每个flow的执行步骤，包括校验环节的判断逻辑，比如你可能会看到类似CP status is not ISSUED或者Amount exceeds held CP value的隐藏提示，这些都是异常的根源。

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