遇到这么一个问题，dubbo服务默认重试三次，所以我接口服务做幂等

Jedis resource=null;
try {
resource = jedis.getResource();
String s = resource.get(order_no + userId + money);
if(StringUtils.isNotEmpty(s)) return ;
resource.set(order_no + userId + money,"1");
}finally {
resource.close();
}
这段代码是我做幂等或者说叫防重处理，我是在redis中用唯一键获取，有数据就直接返回。这种方式发现seata直接把这次调用做成功处理了，发起了整过事务的提交。事实上接口第一次调用失败了，只是超时返回，dubbo马上发起一次重试，而这次重试调口把它做重复数据处理，redis中有数据直接返回,seata以为调成功了，提了整过事务。请问这里是怎么处理幂等或者防重的？
还有一个问题，在测试的时候发现的，就是如果在服务中使用线程去做SQL操作，发现这个SQL的事务不会注册到seata里。看源码原来是这个接口的服务从请求到注册事务，处理业务都用的是同一个线程，把注册事务的ID放在本地线程变量里。所以如果用新的线程去处理SQL时，发现事务XID不在新的线程里，注册不到seata事务管理中。

Start by tracing the reported Dubbo retry path and the Redis/Jedis duplicate check, then inspect how Seata carries the transaction XID through the request thread. Also examine the reported SQL work performed on a new thread. Done requires a maintainer-confirmed scope for handling retries and transaction context propagation; the issue names no files or tests.