bind xid: 172.17.0.15:8092:27681535134726645, while current xid: 172.17.0.15:8092:27681535134726611

[sensenbuxi999]

线上seata服务端从2.0.0升级到2.1.0后，出现 bind xid: 172.17.0.15:8092:27681535134726645, while current xid: 172.17.0.15:8092:27681535134726611，本地无法复现。看了源码，只有两次调用 bind(String xid)且两次xid不一致才会出现，但是本地每次执行只会调用一次 bind(String xid)，什么情况下会多次bind(String xid)呢

[WangzJi]

This XID binding conflict can occur in several scenarios beyond connection pool reuse:

Additional scenarios to check:

1. Transaction propagation: REQUIRES_NEW/NOT_SUPPORTED with suspend/resume
2. Retry mechanisms: Failed transactions being retried with new XIDs
3. XA timeout handling: XA branch timeouts causing context inconsistency
4. Coroutine contexts: If using Kotlin coroutines

Debug info needed:

• Transaction propagation settings
• Any retry/timeout configurations
• Complete stack trace showing the call path
• Whether XA mode is used

This issue likely involves the same connection being used across different transaction contexts without proper cleanup between them.

[sensenbuxi999]

通过traceId确实发现窜线程了
活动服务，请求A-traceId(322f316e7aaf4159b5aa579aa040f5b8) ，事务发起者，申请xid: 172.17.0.15:8092:27681535134726611 调用 二维码服务 06-20 11:49:00.007 执行

活动服务，请求B-traceId(64eab6d5f2084ee3a5106a5b5e1a3f6c) ，事务发起者，申请xid: 172.17.0.15:8092:27681535134726627 调用 二维码服务 06-20 11:49:00.007 执行

很有可能使用了同一个连接，导致请求A的xid 在请求B中使用了，因为bind(String xid)不会调用两次，只会出现上一次请求遗留的xid还没有被清理？

[WangzJi]

Thanks for confirming the thread cross-contamination issue. This needs proper tracking.

Could you create a Issue for this? You have the complete environment details and reproduction context.
Include your traceId analysis and environment details - this will help maintainers investigate what changed between versions and implement a proper fix.

[sensenbuxi999]

好的 我提一个issue