zhenlanghuo

> tcc协议中定义为commit和rollback必须成功，你不能重新从try跑一遍事务 @relxet 你先好好去看下workflow是怎么跑的，如果中间出错了，是怎么重试的

> 这跟workflow没关系，workflow也是几个协议的组合，saga的补偿操作，Tcc的Confirm/Cancel操作，协议上规定，不能允许失败。 @relxet 1. 我这里说的就是workflow模式下执行tcc在某些异常场景下有问题，这个问题跟workflow的执行机制有关系，你撇开workflow来说tcc，有啥用 2. dtm通过resume接口访问业务服务器，让业务服务器继续完成全局事务，官网上是这么写的 而我说的业务服务器会重新跑一遍，workflow的process函数就是这么干的，会用原来的gid重新调用TccBTransOutTry，TccBTransOutTry接口通过barrier做幂等、空补偿、防悬挂，barrier在分支事务存在rollback记录的情况下，再次调用try会返回成功，之后就导致我说的情况，所以这里面是更多的是workflow模式的重试机制或者是barrier的返回问题

> @zhenlanghuo 你不需要push到dtm-examples下面，你只需要在你自己的github账号下面弄好了例子和说明，我就能够直接下载复现问题了 @yedf2 我这边找到原因了，之前dtm-examples引用的dtm的版本是v1.15.1，这个版本workflow存在问题：Workflow.getProgress返回的[]*dtmgpb.DtmProgress永远是一个空数组，具体原因是生成的DtmProgressesReply结构体的json tag的字段名是大写开头的，这个在最新版本中已经修复了

@relxet 我这边找到原因了，之前dtm-examples引用的dtm的版本是v1.15.1，这个版本workflow存在问题，导致wf.progresses没有正确设置，所以每次resume都会重新调用TccBTransOutTry 执行分支事务的任何阶段，都会调用wf.recordedDoInner接口，这个接口会检查一下该阶段是否已经有保存执行结果，v1.15.1的dtm由于上述的问题，导致每次都会获取不到结果，都需要重新执行