hailin
003871aded
## 问题根因
从用户日志分析发现关键错误：
```
15:58:58.318 E/GrpcClient: Mark party ready failed:
INTERNAL: optimistic lock conflict: session was modified by another transaction
```
**问题链条**：
1. markPartyReady 失败（optimistic lock conflict）
2. 但代码没有检查返回值，继续执行
3. 服务器认为 Party 未准备好，不发送 TSS 消息
4. 534个消息堆积（15:58:58.345 + 15:59:28.440）
5. TSS 协议无法进行
6. keygen 卡死
## 修复内容
### 1. 添加 markPartyReady 重试机制
在所有调用 markPartyReady 的地方添加智能重试：
- 最多重试 5 次
- 检测到 optimistic lock conflict 时延迟重试（500ms, 1s, 1.5s, 2s）
- 每次重试记录详细日志
- 5次失败后停止进度收集并返回错误
### 2. 修复位置（6处）
- startKeygenAsInitiator (line 2137)
- joinKeygenViaGrpc (line 1347)
- startSignAsInitiator (line ~1540)
- joinSignViaGrpc (line ~1686)
- startSignAsJoiner (line ~1888)
- co-sign相关函数
### 3. 日志增强
添加详细的重试日志：
- "markPartyReady successful on attempt X"
- "markPartyReady attempt X failed: {error}"
- "Retrying after Xms..."
## 为什么24小时前正常？
**不是 safeLaunch 的问题！** 而是：
1. 优化前，markPartyReady 失败被静默忽略
2. 可能偶尔能工作（没有并发冲突）
3. 现在并发量增加或服务器负载高，冲突频繁
4. 没有重试机制，一次失败就永久卡住
## 验证方法
重新测试创建2-of-3钱包，日志应显示：
- ✅ "markPartyReady successful on attempt 1" 或
- ✅ "Retrying after 500ms..." → "markPartyReady successful on attempt 2"
不应再有：
- ❌ 534个消息堆积30秒不变
- ❌ keygen 永久卡住
## 附加文档
创建了 LOG_ANALYSIS_PARTY1.md 详细分析日志：
- 完整的日志流程分析
- 3个关键问题定位
- 根本原因推断（70% 概率是 markPartyReady 失败）
- 临时和永久解决方案
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| .claude | ||
| api-gateway | ||
| infrastructure | ||
| mpc-system | ||
| scripts | ||
| services | ||
| .env.windows | ||
| docker-compose.windows.yml | ||