Dify 社群回報排程連線未釋放，長駐工作程序可能累積 Redis 閒置連線

Dify 的定時 AI 工作流出現一項資源生命週期問題回報。10 月 22 日建立的議題指出，使用 gevent 集區、消費 schedule_poller 佇列的長駐 Celery 工作程序，可能在派送工作完成後保留 Redis 結果訂閱連線。回報者表示，其正式環境曾累積超過一萬條連線；這是個別部署觀察，並未宣稱已造成服務中斷或資料遺失。議題原文

回報最初來自以 Dify 1.16.1 為基礎的部署，搭配 Celery 5.6.3、gevent 26.4.0 與 redis-py 7.4.0。作者將問題定位至 group(...).apply_async() 的結果回呼路徑：取消訂閱後，負責接收結果的 drainer 仍可能存活，繼續持有後端與連線。依其分析，設定 task_ignore_result=True 也未阻止這條路徑建立訂閱。技術分析

這個差異對維運有實際意義。Celery 官方文件將 task_ignore_result 定義為是否儲存任務回傳值，因此不能單憑這個設定，推定所有結果消費端都已完成資源清理。工程團隊檢查排程健康度時，除了成功率與執行時間，也需要觀察工作結束後的連線是否持續增加。Celery 設定文件

回報建議以持續運行的測試工作程序，跨多個實際派送批次追蹤 Redis 用戶端 ID、閒置時間與最後命令；短命的測試程序會在退出時關閉 socket，可能掩蓋問題。連線數也不應被解讀為每次工作固定增加一條。重現步驟

作者另提出隔離結果後端並明確清理資源的修補方向，但目前可查證的證據仍以原作者回報為主。接下來應關注維護者重現、修補審查與長時間負載驗證；現階段不能將影響範圍外推至所有 Dify 部署或雲端服務。