Hermes Agent 社群回報 Webhook 排程死鎖，共用執行緒池耗盡可讓閘道持續卡住

Hermes Agent 社群於 10 月 27 日提出一項閘道死鎖回報：當多個 Webhook 同時觸發 cron_job，工作可能永久停留在 running，後續觸發也因前次尚未結束而被略過。回報者提供執行緒堆疊與不依賴模型服務的最小程式；另一名專案參與者已將問題納入閘道修復追蹤。截至查核時，議題仍開放，未連結修補分支或 PR。問題回報

依回報分析，Webhook 先透過 asyncio.to_thread 把排程執行交給預設執行緒池；該執行緒再用 run_coroutine_threadsafe(...).result()，同步等待主事件迴圈完成工作。但主迴圈處理狀態寫入與工作執行時，也需要同一個池的空位。一旦所有執行緒都在等待，必要工作便無法開始，形成循環等待。呼叫路徑與重現程式

Python 官方文件明確提醒，執行緒池中的工作等待另一個 Future，可能造成死鎖。Python 3.13 起，預設執行緒上限為 min(32, (os.process_cpu_count() or 1) + 4)；因此回報中的六核心環境只有十個預設工作執行緒，不能把「十個並行工作」當成所有部署的固定門檻。執行緒池文件

這也說明非同步介面仍須檢查等待關係：run_coroutine_threadsafe 回傳的 Future，可供另一個作業系統執行緒等待結果；官方範例則在 .result() 設定逾時。依上述機制推論，部署監測除了事件迴圈是否回應，也應觀察工作狀態是否持續推進，才能辨識執行資源已停滯的情況。跨執行緒排程文件

回報者表示，錯開 Webhook、降低重疊數後未再遇到卡住；這仍是單一環境的觀察。工程團隊接下來應關注是否改用獨立執行器、直接等待主迴圈操作，以及加入逾時與資源存活檢查。正式修復仍須驗證，不能把問題追蹤視為已發布修正。處置建議