Immich-go项目中的资产删除问题分析与解决方案

问题背景

在Immich-go项目（一个用于管理个人照片和视频的开源工具）的使用过程中，用户遇到了上传进度卡在75%的问题。经过分析，发现这与服务器端资产删除操作有关。当用户尝试上传大量文件（约12.5万）时，系统会在处理需要替换的旧资产时出现停滞。

问题现象

用户使用Immich-go 0.18.1版本上传大量媒体文件时，观察到以下现象：

1. 上传进度停滞在75%
2. 日志显示有403个服务器资产需要删除
3. 服务器负载达到100%，有41,000个待处理作业
4. 增加客户端超时设置后，进程会在所有活动作业处理完成后终止

技术分析

资产删除机制

Immich-go的资产删除逻辑设计为：只有当上传的资产是更好的版本（相同文件名、相同拍摄日期）时，才会删除服务器上的旧资产。删除操作是通过批量API调用实现的，将需要删除的资产ID列表一次性提交给服务器。

问题根源

经过深入分析，发现几个关键问题点：

1. 批量删除请求过大：当需要删除的资产数量较多时（如403个），单个请求体可能过大，导致服务器处理困难或超时。

2. 错误处理不完善：当删除请求中某个资产ID无效时，整个批量删除操作会失败，但客户端没有正确处理这种部分失败的情况。

3. 删除操作时机：所有需要删除的资产被累积到最后阶段统一处理，而不是在发现需要替换时立即删除，这增加了最终阶段的处理压力。

解决方案

项目维护者针对这些问题实施了以下改进：

1. 立即删除策略：修改为在发现需要替换的资产时立即删除，而不是累积到最后统一处理。这分散了删除操作的压力。

2. 错误处理增强：改进了对删除操作失败的处理逻辑，确保单个资产删除失败不会影响整体进程。

3. 请求体优化：对批量删除请求进行了优化，防止因请求体过大导致的问题。

实施效果

经过这些改进后：

• 上传过程不再会在75%处停滞
• 系统能够更稳定地处理大量资产的替换操作
• 错误处理更加健壮，部分失败不会导致整个进程中断

最佳实践建议

对于使用Immich-go处理大量媒体文件的用户，建议：

1. 使用最新版本的Immich-go，其中包含了这些修复和改进。

2. 对于特别大的媒体库，可以考虑分批次上传，而不是一次性处理所有文件。

3. 监控服务器资源使用情况，确保有足够的处理能力。

4. 如遇问题，可以启用调试日志（使用-debug-counters参数）帮助诊断问题。

总结

Immich-go项目通过这次问题修复，显著提升了处理大量媒体文件时的稳定性和可靠性。这体现了开源项目通过社区反馈不断改进的典型过程，也为处理类似批量操作提供了有价值的参考案例。