hailin
37d3300b17
## 问题背景 用户 D25122700018 的层级已解锁（unlocked_level_depth=5），但缺少 TEAM_LEVEL 算力记录。 其下级用户 D25122700019 的团队算力被错误地分配给了 D25122700015（level 2）而非 D25122700018（level 1）。 ## 根本原因分析 1. 源系统数据顺序正确： - D25122700018: order_id=55, created_at=2026-01-09 11:57:01 (先认种) - D25122700019: order_id=57, created_at=2026-01-09 12:00:38 (后认种) 2. Kafka 消息顺序错误： - D25122700019: offset=732, synced_at=10:15:32 (先处理) - D25122700018: offset=798, synced_at=10:15:41 (后处理) 3. 原因：Debezium snapshot 按 PostgreSQL 物理存储顺序（heap order）读取数据， 而非按主键顺序。即使 topic 只有 1 个分区，消息顺序仍然错误。 4. 后果：当处理 D25122700019 的认种时，D25122700018 的 unlocked_level_depth 还是 0， 导致 D25122700019 的 TEAM_LEVEL 算力跳过 level 1 直接分配给 level 2。 ## 解决方案 对 planting_orders 阶段实现"收集-排序-处理"模式： 1. 先收集所有消息到内存数组（不立即处理） 2. 按 order_id（源系统主键）升序排序 3. 再按排序后的顺序逐条处理 这确保上游用户的认种记录先于下游用户处理，避免算力分配错误。 ## 受影响用户案例 - 上游用户: D25122700018 (order_id=55) - 下游用户: D25122700019 (order_id=57, 58, 59) - 错误分配: D25122700019 的 TEAM_LEVEL 给了 D25122700015 而非 D25122700018 ## 回滚方法 如需回滚此修改，将 consumePhaseToEnd 方法中的判断条件改为 false： ```typescript const needsSorting = false; // 原: phase.tableName === 'planting_orders' ``` 或直接 revert 此 commit。 ## 风险评估 - 业务逻辑完全不变，只改变处理顺序 - user_accounts 和 referral_relationships 阶段保持原有逻辑 - 内存开销可控（10000 条记录约 5MB） - 排序开销可忽略（O(n log n)） Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| prisma | ||
| src | ||
| .env.example | ||
| DEVELOPMENT_GUIDE.md | ||
| Dockerfile | ||
| nest-cli.json | ||
| package-lock.json | ||
| package.json | ||
| tsconfig.json | ||