修复用户日志收集器fund_logs进度显示问题

时间: 2025年06月23日 01:15-01:21
状态: ✅ 已完成

问题描述

用户反馈user_log的fund_log收集有问题，需要清空重新收集并检查解决问题。

问题分析

1. 初始检查

fund_logs表有205条记录，最大ID为515845
user_logs表中有205条source_table='fund_logs'的记录
但收集器显示"最后处理ID 515840, 待处理 5 条"，进度显示不正确

2. 根本原因

发现问题在于CollectUserLogsCommand中的getLastProcessedIdFromUserLogs方法：

// 问题代码
$lastLog = \App\Module\Game\Models\UserLog::where('source_table', $sourceTable)
    ->where('source_type', $sourceType)  // 这里有问题
    ->orderBy('source_id', 'desc')
    ->first();

问题分析：

FundLogCollector使用动态source_type，根据备注内容设置不同的类型（如"system"、"farm_upgrade"等）
但命令中的进度查询使用固定的source_type（"system"），导致查询不到正确的最后处理记录
BaseLogCollector的getLastProcessedId方法是正确的，只使用source_table过滤

3. 数据验证

fund_logs的记录被正确收集，按source_type分布：

system: 166条（管理员操作等）
farm_upgrade: 39条（土地升级消耗）

解决方案

修复进度计算逻辑

修改CollectUserLogsCommand::getLastProcessedIdFromUserLogs方法，对fund_logs表特殊处理：

elseif ($sourceTable === 'fund_logs') {
    // 对于fund_logs表，使用动态source_type，只按source_table查询
    // 这与BaseLogCollector的getLastProcessedId方法保持一致
    $maxId = \App\Module\Game\Models\UserLog::where('source_table', $sourceTable)
        ->max('source_id');
    return $maxId ?: 0;
}

实施过程

1. 问题诊断

# 检查数据状态
SELECT COUNT(*) FROM kku_fund_logs;  # 205条
SELECT COUNT(*) FROM kku_user_logs WHERE source_table = 'fund_logs';  # 205条
SELECT MAX(source_id) FROM kku_user_logs WHERE source_table = 'fund_logs';  # 515845

2. 代码修复

修改app/Module/Game/Commands/CollectUserLogsCommand.php
在getLastProcessedIdFromUserLogs方法中添加fund_logs特殊处理逻辑

3. 验证修复

php artisan game:collect-user-logs --detail

修复后输出：

🔧 fund: 最后处理ID 515845, 待处理 0 条  ✅
🔧 item: 最后处理ID 11802, 待处理 0 条
🔧 farm_harvest: 最后处理ID 432, 待处理 0 条
🔧 farm_upgrade: 最后处理ID 432, 待处理 0 条
🔧 point: 最后处理ID 372, 待处理 0 条

技术细节

FundLogCollector的动态source_type机制

private function getSourceTypeByRemark(string $remark): string
{
    $remarkInfo = $this->parseRemark($remark);
    
    if (isset($remarkInfo['source'])) {
        switch ($remarkInfo['source']) {
            case 'land_upgrade':
                return REWARD_SOURCE_TYPE::FARM_UPGRADE->value;
            case 'admin_operation':
                return REWARD_SOURCE_TYPE::ADMIN_GRANT->value;
            // ... 其他类型
            default:
                return REWARD_SOURCE_TYPE::SYSTEM->value;
        }
    }
    
    return REWARD_SOURCE_TYPE::SYSTEM->value;
}

消息转换示例

土地升级："消耗组:43,来源:land_upgrade,ID:380" → "土地升级消耗钻石 300"
管理员操作："系统充值 - 用于Transfer模块测试" → "管理员操作（系统充值 - 用于Transfer模块测试）获得钻石 10000"

验证结果

1. 进度显示正确

fund收集器显示：最后处理ID 515845, 待处理 0 条 ✅
与实际数据一致

2. 数据完整性

fund_logs表：205条记录
user_logs表中fund_logs来源：205条记录
数据完全一致 ✅

3. 消息质量

system类型：166条，显示管理员操作信息
farm_upgrade类型：39条，显示土地升级消耗信息
消息格式友好，内容准确 ✅

提交信息

git commit -m "修复用户日志收集器fund_logs进度显示问题

- 修复CollectUserLogsCommand中getLastProcessedIdFromUserLogs方法
- 对fund_logs表使用source_table过滤而非source_type过滤
- 解决FundLogCollector使用动态source_type导致的进度计算错误
- 现在fund收集器正确显示已处理完所有记录
- fund_logs表的205条记录已全部正确收集并转换为用户友好消息"

总结

✅ 问题已解决：

修复了fund_logs收集器的进度显示问题
保持了FundLogCollector的动态source_type机制
确保了数据收集的完整性和准确性
所有fund_logs记录已正确转换为用户友好的日志消息

关键改进：

统一了进度计算逻辑，避免了动态source_type导致的查询问题
保持了BaseLogCollector和Command层的一致性
提高了系统的健壮性和可维护性

23日0115-修复用户日志收集器fund_logs进度显示问题.md 4.8 KB History Raw