Failed to clear the logs from WORKFLOW LOG_CEANUP

快速结论：该报错通常出现在 Dify 自托管环境中，用户配置了工作流日志清理参数（如保留最近 3 天）并手动修改了 Docker 容器系统时间后，日志仍未被清理。优先排查 Celery Beat 定时任务是否真正触发，以及 LOG_TZ 时区配置是否正确，而不是依赖手动改系统时钟。

适用环境：Dify V1.13.3，Self Hosted（Docker）部署。

最快修复方案：在 .env 中正确设置 LOG_TZ（例如 LOG_TZ=Asia/Shanghai），不要手动修改容器系统时钟，让 Celery Beat 在真实时区的凌晨 2:00 自动触发清理任务；如需立即清理，可在 worker 容器中执行 flask clean-workflow-runs --before-days 3 --batch-size 100。

注意事项：手动修改 Docker 容器系统时钟不会触发 Celery Beat 的调度，因为调度器使用自身内部 tick 机制，这是该 Issue 中最可能的核心原因；LOG_TZ 默认值为 UTC，若未设置可能导致清理时间与预期不符；使用 WORKFLOW_LOG_CLEANUP_SPECIFIC_WORKFLOW_IDS 时需传入 Workflow ID 而非 App ID。

问题场景

用户在 Dify V1.13.3 自托管（Docker）环境中，配置了工作流日志清理相关参数（期望仅保留最近 3 天的应用日志），重启了所有 Dify 应用，并将容器时间手动设置为凌晨 2 点。然而 Dify 应用日志并未按预期仅保留最近 3 天，清理任务似乎未生效。用户通过 docker logs docker-worker_beat-1 2>&1 | grep -i "workflow" 查看 worker beat 日志进行排查。

报错原文

Failed to clear the logs from WORKFLOW LOG_CEANUP

原因分析

根据 Issue 讨论，最可能的原因是：手动修改 Docker 容器系统时钟不会触发 Celery Beat 的定时任务，因为 Celery Beat 调度器使用自身内部的 tick 机制，而非直接读取系统时钟变化。用户截图中显示手动将时间改为凌晨 2 AM，但这并不能让定时任务按预期触发。

另一个可能的因素是时区不匹配：清理任务依据 LOG_TZ 环境变量在凌晨 2:00 执行，而 LOG_TZ 默认值为 UTC。如果用户未设置 LOG_TZ，实际触发时间会与本地时间预期不一致。

此外，若使用了 WORKFLOW_LOG_CLEANUP_SPECIFIC_WORKFLOW_IDS，需确认传入的是 Workflow ID 而非 App ID，否则清理范围可能不正确。

环境排查

确认 Dify 版本：V1.13.3（Issue 中确认）。
确认部署方式：Self Hosted（Docker）。
检查 LOG_TZ 环境变量是否已设置（默认 UTC）。
检查 WORKFLOW_LOG_CLEANUP_ENABLED 是否已在 beat 容器中生效：docker exec docker-worker_beat-1 env | grep WORKFLOW_LOG_CLEANUP_ENABLED。
检查 celery-beat 日志中是否有 "Start clean workflow run logs" 消息，确认任务是否被触发。
若使用 WORKFLOW_LOG_CLEANUP_SPECIFIC_WORKFLOW_IDS，通过 SQL 确认传入的是 Workflow ID：SELECT workflow_id FROM apps WHERE id = '<your-app-id>'。

解决步骤

停止手动修改 Docker 容器系统时钟，改回正常时间同步方式。
在 .env 中正确设置时区，例如：LOG_TZ=Asia/Shanghai，确保清理任务在本地时区凌晨 2:00 触发。
重启 Dify 相关服务，使环境变量生效。
确认 beat 容器已加载清理相关环境变量：docker exec docker-worker_beat-1 env | grep WORKFLOW_LOG_CLEANUP_ENABLED。
查看 celery-beat 日志，确认是否出现 "Start clean workflow run logs" 消息，以判断任务是否被触发。
若需立即验证清理逻辑，在 worker 容器中执行：docker exec -it <worker-container-name> flask clean-workflow-runs --before-days 3 --batch-size 100，观察终端反馈是否真正删除了记录。
若使用了 WORKFLOW_LOG_CLEANUP_SPECIFIC_WORKFLOW_IDS，通过 SQL 获取正确的 Workflow ID 并替换配置中的 App ID。

验证方法

通过 docker logs docker-worker_beat-1 2>&1 | grep -i "workflow" 确认是否出现 "Start clean workflow run logs" 消息；同时观察应用日志中超过保留天数的记录是否被删除。若手动执行 flask clean-workflow-runs 能正常删除记录，而定时任务不触发，则问题在于调度而非清理逻辑本身。