rwadurian/backend/mpc-system/services
hailin 704ee523c9 fix(android): 添加协程全局异常处理器,防止未捕获异常崩溃 [P2]
【架构安全修复 - 防止协程未捕获异常导致应用崩溃】

## 问题背景

协程中的未捕获异常会传播行为:
1. 子协程中的异常会传播到父协程
2. SupervisorJob 虽然防止子协程失败取消其他子协程,但不捕获异常
3. 未处理的异常最终会导致应用崩溃

## 存在的风险

### 场景 1: 后台消息收集失败
- 原问题: messageCollectionJob 中网络异常未捕获
- 后果: 整个 repositoryScope 取消,所有后台任务停止 → 功能完全失效

### 场景 2: 事件订阅异常
- 原问题: sessionEventJob 中解析事件数据异常
- 后果: 事件订阅中断,无法接收后续事件 → 签名/密钥生成卡住

### 场景 3: RPC 调用失败
- 原问题: getBalance 等方法中 JSON 解析失败
- 后果: 应用崩溃 → 用户体验极差

## 修复方案

### 添加 CoroutineExceptionHandler

在 repositoryScope 中配置全局异常处理器:

### 异常分类处理

根据异常类型采取不同策略:
1. CancellationException - 正常的协程取消,仅记录日志
2. 网络异常 (SocketTimeoutException, UnknownHostException, IOException)
   - 记录警告日志
   - 可以触发重连逻辑
3. 状态异常 (IllegalStateException, IllegalArgumentException)
   - 记录错误日志和堆栈
   - 可以重置状态或通知 UI
4. 其他未知异常
   - 记录详细错误信息
   - 防止应用崩溃,保持功能可用

## 修复的崩溃场景

### 场景 1: 网络突然断开时消息收集崩溃
- 原问题: messageCollectionJob 中 grpcClient.routeMessage() 抛出 IOException
- 修复前: 异常传播导致 repositoryScope 取消 → 所有后台任务停止
- 修复后: 异常被 CoroutineExceptionHandler 捕获 → 记录日志,其他任务继续运行

### 场景 2: 服务端返回格式错误导致解析崩溃
- 原问题: JSON 解析失败抛出 JsonSyntaxException
- 修复前: 应用直接崩溃
- 修复后: 异常被捕获,记录错误日志,用户可继续使用其他功能

### 场景 3: partyId 未初始化导致的崩溃
- 原问题: 虽然已添加 requirePartyId() 检查,但如果异常未捕获仍会崩溃
- 修复前: IllegalStateException 导致应用崩溃
- 修复后: 异常被捕获,用户看到错误提示而非应用崩溃

### 场景 4: 并发竞态条件导致的状态异常
- 原问题: 快速切换页面时状态不一致抛出 IllegalStateException
- 修复前: 应用崩溃,用户丢失所有未保存数据
- 修复后: 异常被捕获,状态可以恢复,功能继续可用

## 影响范围

### 修改的代码位置
- TssRepository.kt - 添加 coroutineExceptionHandler
- repositoryScope 配置 - 添加异常处理器到 CoroutineScope

### 行为变化
- BEFORE: 协程中未捕获异常导致应用崩溃
- AFTER: 异常被捕获并记录,应用继续运行

### 日志增强
所有未捕获异常都会记录:
- 异常类型和消息
- 协程上下文信息
- 完整堆栈跟踪
- 根据异常类型的分类标签

## 测试验证

编译状态:  BUILD SUCCESSFUL in 42s
- 无编译错误
- 仅有警告 (unused parameters),不影响功能

## 最佳实践

这个修复符合 Kotlin 协程最佳实践:
1. SupervisorJob - 子协程隔离
2. CoroutineExceptionHandler - 全局异常捕获
3. 明确的异常分类处理
4. 详细的日志记录

## 注意事项

1. CoroutineExceptionHandler 仅捕获未处理的异常
   - 已在 try-catch 中捕获的异常不会触发
   - 这是最后一道防线,不应替代局部异常处理

2. CancellationException 不应被捕获
   - 它是协程取消的正常机制
   - 在 handler 中识别并忽略

3. 重要操作仍应使用 try-catch
   - 关键路径(签名、密钥生成)应保留局部 try-catch
   - 这样可以提供更精确的错误处理和恢复

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2026-01-26 21:51:37 -08:00
..
account Revert "fix(co-keygen): convert threshold at storage time to match tss-lib convention" 2025-12-31 10:24:25 -08:00
message-router fix(message-router): prevent subscription race condition on gRPC reconnect 2026-01-01 10:04:11 -08:00
server-party fix(participate_signing): 恢复 Execute 方法的 UserShareData 分支 2026-01-26 19:00:52 -08:00
server-party-api fix(context): use parent context instead of Background() to allow proper cancellation 2025-12-06 06:36:34 -08:00
server-party-co-managed fix(co-managed): 使用数据库中的 PartyIndex 而非循环索引 2026-01-26 20:24:32 -08:00
service-party-android fix(android): 添加协程全局异常处理器,防止未捕获异常崩溃 [P2] 2026-01-26 21:51:37 -08:00
service-party-app fix(tss): 修复备份恢复后签名失败的问题 2026-01-20 00:39:05 -08:00
session-coordinator feat(session): broadcast participant_joined event via gRPC for real-time UI updates 2026-01-01 08:34:47 -08:00
tss-wasm feat(tss): add real-time round progress from msg.Type() parsing 2026-01-01 22:41:51 -08:00