Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Action Scheduler queue cleanup fatals with "Unidentified action" after concurrent deletion

已關閉
#1,369 3 則留言 0 個 reaction 已指派 2 人 在 GitHub 檢視

@Soare-Robert-Daniel 已經在處理了。

開始於 2026年9月30日。

  • #1390 來自 @pirate-bot —— 未關閉

評估

這個 Issue 還沒有評估資料。

描述

bug-report bug-report-triage

Summary

Visualizer's scheduled-action cleanup can terminate with an uncaught InvalidArgumentException when an action selected for failure processing is deleted or otherwise disappears before its status update. Cleanup is expected to tolerate that race and continue processing the queue; instead, the request ends in a fatal error. This can interrupt scheduled work on an affected site.

Customer context

  • Product / area: Visualizer scheduled database refresh / bundled Action Scheduler
  • Version: 4.0.7
  • Environment: WordPress site; PHP, WordPress, database, and hosting versions were not provided
  • Integration / third party: Bundled woocommerce/action-scheduler 3.9.3
  • Reported error / symptom: One captured uncaught InvalidArgumentException states that an action could not be marked failed because another process may have deleted it
  • Impact: One queue-cleanup request terminated; broader scheduling impact is unknown

Reproduction notes

Runtime reproduction was not performed. Evidence-backed inferred workflow:

  1. Run Visualizer 4.0.7 with its bundled Action Scheduler active.
  2. Have queue cleanup query a stale action in in-progress status.
  3. Between that query and the status update, let another process delete the action or alter it so the update affects no row.
  4. Observe an uncaught InvalidArgumentException from ActionScheduler_DBStore::mark_failure().

The submitted crash log confirms steps 2–4 occurred on one site, but it does not identify the competing process or action hook.

Diagnosis

Conclusion

The fatal is confirmed as a dependency race exposed by Visualizer's bundled Action Scheduler. The captured stack shows ActionScheduler_QueueCleaner::mark_failures() selecting an action and ActionScheduler_DBStore::mark_failure() throwing when the subsequent database update affects no row. Inspection confirms that the cleaner does not handle that exception. Upstream issue woocommerce/action-scheduler#970 describes the same fatal, remains open, and is labeled as a high-priority bug.

Where this likely occurs
  • Scheduled database-refresh subsystem: classes/Visualizer/Module/Setup.php — Visualizer_Module_Setup::schedule_refresh_db_action() lines 486–504 schedules the visualizer_schedule_refresh_db recurring action through Action Scheduler when its API is available.
  • Dependency bootstrap: index.php — Visualizer startup callback approx. lines 148–157 loads the bundled Action Scheduler entry point.
  • Dependency selection: composer.lock — package record lines 181–221 locks woocommerce/action-scheduler 3.9.3 at commit c58cdbab17651303d406cd3b22cf9d75c71c986c; tag v4.0.7 contains this lock.
  • Queue-cleanup path: vendor/woocommerce/action-scheduler/classes/ActionScheduler_QueueCleaner.php — ActionScheduler_QueueCleaner::mark_failures() lines 206–228 queries stale running action IDs and calls mark_failure() for each without an exception boundary.
  • Data-store path: vendor/woocommerce/action-scheduler/classes/data-stores/ActionScheduler_DBStore.php — ActionScheduler_DBStore::mark_failure() lines 1215–1233 throws the reported exception when its update affects no row.
  • Git history: Visualizer commit bc14d4b8 introduced the Action Scheduler dependency and loading path; it is present from v4.0.0 through v4.0.7. This identifies the feature boundary but does not prove a regression because the earlier releases did not provide the same scheduler workflow.
Engineering notes

Visualizer loads its packaged Action Scheduler conditionally and uses the global as_* API. On sites with multiple Action Scheduler copies, normal package version arbitration may determine which copy executes; the crash path identifies a copy under Visualizer's packaged vendor/woocommerce/action-scheduler directory. The race window lies between querying stale running actions and updating each action, so concurrent cleanup, deletion, or another process changing the row can trigger it. The exact action hook and the process that removed or changed the reported row are unknown.

Test coverage status

No relevant Visualizer unit or e2e coverage was found during inspection for Action Scheduler cleanup, concurrent action deletion, or mark_failure() exceptions. The upstream dependency's test suite was not available in the Visualizer checkout.

What to verify or explore next
  • May be worth reproducing with Visualizer 4.0.7 by placing an action in stale in-progress state, deleting or changing it after the cleaner query, and running queue cleanup.
  • If reproducible, checking both WP-Cron and asynchronous queue-runner cleanup contexts may establish the affected execution surfaces.
  • May be worth confirming behavior when another active plugin registers a newer or older Action Scheduler copy before Visualizer.
  • Checking the packaged release ZIP can confirm that its dependency source exactly matches lock reference c58cdbab17651303d406cd3b22cf9d75c71c986c.
Unknowns / follow-up

The report contains one occurrence and no site load, database, concurrency, or action-hook details. It is unknown whether the vanished action belonged to Visualizer or another component sharing the scheduler tables.

Confidence

Confidence: 94/100

The captured stack exactly matches a documented race in the Action Scheduler dependency bundled by Visualizer 4.0.7, and repository inspection confirms that the exception from mark_failure() is not handled by the queue cleaner. Upstream issue woocommerce/action-scheduler#970 independently classifies the same fatal as a bug; no matching Visualizer issue was found.


Source: automated uninstall feedback — visualizer, 2026-08-30
Generated by bug-report-triage (ID: bug-report-triage_6a950a8cd8e195.34071552)

主要語言
PHP
星號
108
分支
29
平均合併
3 天 13 小時
30 天內合併 PR
8

環境準備

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

Codeinwp/visualizer 的其他 Issue

查看 Codeinwp/visualizer 的全部 Issue

相似的 Issue

更多 PHP Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。