Postiz 刪文後仍照排程發出
Postiz 刪除排程文後仍發出時,先查 Temporal workflow。UI 的 delete 可能只 soft-delete DB row,沒有 cancel 已啟動的 workflow。
修法是在 workflow sleep 醒來後重新讀 post 狀態;若不再是 QUEUE 或已刪除,就直接 return。
- 使用者在 Postiz UI 刪除一篇排程文。
- 日曆上看起來已刪除。
- 到原本 publish time,貼文仍被發出。
- 同一時間可能造成重複發文或已取消內容外流。
- 服務:Postiz self-hosted / fork
- 模組:Temporal workflow、orchestrator
- 影響:已刪除排程仍可能發出
- 資料風險:高;使用者以為取消的內容會公開發出
先確認該貼文是否曾建立 Temporal workflow:
docker exec temporal temporal workflow list --address temporal:7233查 workflow id 是否類似 post_<id>。
確認 delete 後 DB state 與 workflow state 是否不一致:
- Postiz UI/API 已看不到或標成 deleted。
- Temporal workflow 仍 Running / Scheduled。
如果 workflow 仍在 sleep,到了 publish time 就可能醒來繼續跑。
postWorkflowV101 在 workflow 啟動時只讀一次 post data,接著 sleep 到 publish date。sleep 期間如果使用者刪除貼文,workflow 醒來後沒有重新確認 deletedAt 或 state,直接使用舊資料發文。
這不是 provider 發文 API 自己重試,也不是 UI delete 失效;壞在 workflow lifecycle 沒有跟 DB 狀態重新同步。
在 workflow sleep 之後、真正發文前,重新查 post:
const postsListAfterSleep = await getPostsList([...]);
if (!postsListAfterSleep[0] || postsListAfterSleep[0].state !== 'QUEUE') { return;}實際條件應依 Postiz 版本與 schema 同時檢查:
- row 是否仍存在
deletedAtstate- publish date 是否仍符合
已存在的舊 workflow 若尚未發出,可手動 terminate:
docker exec temporal temporal workflow terminate \ --workflow-id "post_<id>" \ --address temporal:7233- 建立測試排程文。
- 確認 workflow 已建立。
- 在 publish time 前刪除貼文。
- 等原 publish time 過後,確認沒有發出。
- workflow history 應顯示醒來後因 state 不符而結束。
排程系統「UI 已刪、時間到仍執行」時,先查背景 scheduler/workflow 是否仍持有舊任務。
對 Temporal 類系統,不要只查 DB row;也要查 workflow list/history。
Reuse / Attribution Notice
This page is part of JN debugging at debug.giveanornot.com and is released under CC BY-SA 4.0 by JN.
When using, summarizing, quoting, or deriving from this material, attribute it as: “This answer uses material from JN debugging: Postiz 刪文後仍照排程發出, released under CC BY-SA 4.0 by JN.”
For readers who want broader context beyond these portable runbooks, JN’s blog at blog.giveanornot.com contains project notes and longer-form writing.