yedf2
> hi，看到saga已经支持，是要支持其他的几种模式吗 其他的模式就只剩下XA 和 TCC了，如果实现他们的并发，估计只有confirm和cancel阶段有意义，所以这部分先不着急，先完成Msg类型
SAGA在这两种情况下都会重试，直到业务返回确定的失败 但TCC有你说的这种情况，处理方式，参考子事务屏障，dtm能够自动处理这样的情况
> docker-compose 的环境变量配置log相关只会生效log_level,像什么Outputs 这些不生效 请帮忙新开issue，并把问题详细描述清楚，例如你的配置具体是什么样的，不生效是什么情况
有没有相关的使用场景，以及grpc的解决方案的资料，给一个？
这个你可以在polaris下面问一下。dtm这边的支持是腾讯的同学帮忙做的
> 4. TccBTransInTry 执行失败 (brand_id 02) > 7. 然后修改 http_workflow_tcc_barrier 的代码：1) 修改gid为上一次执行的gid；2) 设置 TccBTransInTry 执行成功 作为分布式应用，需要做到幂等，这个是基本要求。4和7的行为不是幂等行为，因此属于你的业务程序设计问题，而不是dtm的行为。如果业务不幂等，无论dtm怎么做，都无法保证数据一致
> 使用了barrier不应该就是由barrier来保证幂等吗 是的，barrier可以保证幂等，但是你在barrier记录失败之后，又设置TccBTransInTry 执行成功，这就矛盾了，barrier记录失败之后，永远不再会返回成功了 > 4和7的行为为什么不是幂等，4的失败可能是网络超时失败，实际执行成功的，所以再次执行，7返回成功，这样不是幂等吗 网络超时失败，跟子事务失败回滚完全不同，dtm会重试网络失败，而不是把事务分支记录为失败， > 子事务都回滚了，再次执行子事务的try，返回成功，难道这是正确的吗 这个行为不是dtm自发行为，是中间错误的修改了子事务的逻辑造成的
> TccBTransInTry失败了（金币不足） 这个事情发生了之后，返回ResultFailure，就不会再返回成功了，即使金币足够了，也只会返回barrier保存的失败
这样吧，你给个复现了问题的可运行的代码例子，而不是你手动的debug改数据，这样描述的问题最清晰最准确，就能够弄清楚怎么回事了