[Bug]: CheckBatchCost stale sweep excludes completed statuses that its own job selection includes, so a completed unprocessed row is never s

快速结论：该报错发生在 LiteLLM 后台批量成本核算（CheckBatchCost）任务中，因清理过期任务时排除了 completed/complete 状态，而轮询器却会持续选择这类状态的任务，导致已完成但未标记 batch_processed 的行永远不会被清理，无限占用轮询槽位。优先确认 LiteLLM 版本是否已包含 #36714 的修复。

适用环境：LiteLLM v1.94.3（Issue 已确认复现版本）；当前 staging 版本已通过 PR #36714 修复。

最快修复方案：升级 LiteLLM 至包含 PR #36714 的版本，该修复已确认能让已完成的过期行正常退役，轮询器不再被阻塞。

注意事项：如果无法立即升级，可考虑人工将卡住的 completed 行手动标记为 stale_expired，但这只是权宜之计，需确认数据库中有 batch_processed 列且 schema 版本匹配。

问题场景

在 LiteLLM Proxy 环境中，后台任务 check_batch_cost() 周期性执行批量成本核算。当批次状态为 completed 但 batch_processed=false 时，清理任务（_cleanup_stale_managed_objects）不会将其标记为 stale_expired，而轮询器（job selection）却持续选中该行，导致它无限期占用轮询配额，使后续新批次排队等待，且不产生任何错误日志。

报错原文

[Bug]: CheckBatchCost stale sweep excludes completed statuses that its own job selection includes, so a completed unprocessed row is never swept and is polled indefinitely

原因分析

问题根源在于同一类中两个查询条件不一致：

清理逻辑（sweep）的 status not_in 列表包含 completed 和 complete，因此不会将已完成的行标为过期；
而轮询任务（job selection）的 status not_in 列表不包含这两个状态，导致已完成但未处理的行不断被选中。

结果是这类行永远不会被清理，且每次轮询都会返回，占用 MAX_OBJECTS_PER_POLL_CYCLE 中的固定槽位，使新批次排队等待。

环境排查

确认 LiteLLM 版本是否为 v1.94.3 或更早（该版本已确认存在此问题）；
检查数据库 schema 是否存在 batch_processed 列（该列的存在会改变轮询器的查询逻辑）；
查看 MANAGED_OBJECT_STALENESS_CUTOFF_DAYS 配置值（Issue 中为 7 天），确认过期时间设置。

解决步骤

升级 LiteLLM 至包含 PR #36714 的版本，该修复已确认能正确退役已完成且过期的批次行；
如果暂不能升级，可通过数据库客户端手动将卡住的 completed 且 batch_processed=false 的行的 status 改为 stale_expired，释放轮询槽位（注意：需先确认该行确实已完成后无需再处理）；
升级后重启 LiteLLM Proxy 服务，使修复生效。

验证方法

升级后观察 litellm_managedobjecttable 中 status='completed' 且 batch_processed=false 且创建时间超过 MANAGED_OBJECT_STALENESS_CUTOFF_DAYS 的行，确认它们会被标记为 stale_expired；同时确认日志中不再出现类似“marked 1 stale managed objects（应为 2）”的输出，且后台轮询不再无限选择这些行。