yedf2
这个要诊断一下是否出现了网络问题。你是什么样的环境，如何能够复现这个问题
Can you make a small typo PR? I'll merge it and you'll be granted privileges to run CI. After that, you can fix the CI error for this PR.
接口调用超时是比较短的，不是通过timeoutToFail设置的。接口调用一般不会超过3秒的。一个接口调用超过3秒了，通常意味着设计有问题。
这个并不是放弃回滚操作，而是说如果这一次运行超过了时间，那么这次不再继续处理这个事务，等待下一次到时间再尝试
有需要的特性就会更新。
> 当创建店铺事务子步骤失败后，代码没有执行预期的回滚逻辑 你需要按照约定返回失败，其他的失败，DTM不清楚是暂时的失败还是业务真正失败了，所以会不断地尝试 > 直接又执行创建用户的正常事务逻辑 对于分布式事务来说，需要子业务时幂等的，可以看看dtm相关的文档 dtm-examples下面有许多的例子，参考例子做一下实验。如果你的问题能够通过例子复现，那么就容易解决了
这个需要熟悉goframe的人来提PR
您好，您可以通过dtm-examples项目，修改其中的例子，复现你的问题，然后把详情发到这个issue里。 只是看你的片段代码，我也无法准确诊断出您的问题
对于使用分布式事务的应用来说，通常瓶颈不在这个序列化和反序列化这里，所以你担心的这个问题，最好是有真实压力出现时，再考虑优化。 另一个方向是，当序列化和反序列化的压力比较大是，建议grpc，因为grpc是二进制协议，序列化和反序列化会更高效
从高维度的设计来说，payloads是每个分支的payload，在http协议里面，会按照每个payload分开保存到DB里，所以从client就分开序列化并传送是很自然的。而特意优化，减少一个中间过程，看起来是更复杂的设计。 “因为要透传的数据很大，所以就发现有巨大的字符串常驻在托管堆中。”这个会有具体什么问题吗？目前看go的垃圾收集好像没有太大的问题