seata版本1.5.1，注册到nacos两个节点，客户端采用saga模式，正常情况下，一个事务请求会被分配到一个seata节点管理，如图：
业务流程正常结束，事务被committed。但测试的时候经常发现，当一个事务请求被分配到一个节点后，这个事务的部分日志会出现在另一个节点，那么此时，就算业务流程已经执行完毕，也不会打印committed那条日志，如图： 接收请求的seata节点日志：
另一个节点：
之后，seata服务节点会一直等待超时，这个超时时间是由这个参数：transOperationTimeout控制的，默认值1800000ms。 到了超时时间，若客户端与服务端已经断开连接，服务端就会一直报错：Failed Rollback，1s一次。 若连接未断开，则会打印如下日志：
对客户端进行整体回滚，但这之前业务其实已经执行成功了！
就算不配置Nacos集群，在单节点的Nacos配置时，Saga模式也有同样的问题。https://github.com/seata/seata/issues/4853
我这边测试了一下，单节点不会出问题。同时在V1.4.2版本下，多节点一样会有问题
我是基于github上的一个例子修改的：https://github.com/StarlightWANLI/local-saga 客户端配置： seata.enabled=true seata.tx-service-group=local_saga seata.service.vgroup-mapping.local_saga=default seata.registry.type=nacos seata.registry.nacos.server-addr=xxxx:8848 seata.registry.nacos.application=seata-server seata.registry.nacos.group=SEATA_GROUP seata.registry.nacos.namespace=xxx seata.registry.nacos.username=xxx seata.registry.nacos.password=xxx
服务端： registry: type: nacos nacos: application: seata-server server-addr: xxx:8848 namespace: xxx group: SEATA_GROUP username: xxx password: xxx cluster: default
committed的那个xid和最后rollback的xid我看着不是同一个呀，有没有更详细点的日志，可以呼应上的
谢谢[Shi-Le-Zhi](https://github.com/Shi-Le-Zhi)。
我也用过你说的这个示例进行过测试。单节点V1.5.X也是有问题的，V1.4.2没有问题。
我发现的问题表现形式如下：
通过：http://localhost:8080/create 发起调试命令，不论是正常参数还是改变参数值模拟异常，
测试方法都能正常返回。分支事务也如所预期的一样。
startParams.put("mockReduceBalanceFail","true");
但问题是：过半小时后，1800,000后，会对所有正常提交的事务进行补偿操作。
在数据库上的表现是：如果V1.4.2版本，测试时，这个表的记录会自动清除。
select * from global_table
但V1.5.X 版本，这个表的记录的情况是：测试完成后，记录是存在的，但等到半小时的回滚事件执行完后，这个表的记录也就不存在了，但显然不是预期的结果。对，我说的可能不够清楚，这其实是两次调用，有committed的事务是正常情况。rollback的那个是没有committed的，但是业务已经正常结束了。 这个问题不是百分百出现，出现几率挺大的。
从这个现象看，回滚似乎是依据global_table表的记录情况来决定的，不知道我是其它原因引起的，还是V1.5.X版本的问题，源码一时消化不了，还请专家指点。
大佬，这个问题有结论吗
兄弟，问题有解决吗
事务状态是否处于committing阶段？
异常情况下，日志分为上下两段，请求也是打在了8091节点上：
奇怪的是，8092节点上也出现了一条日志，这条日志本来应该出现在8091节点上：
