Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#1,369 0 comentários 0 reações 1 responsável Ver no GitHub

Mantenedores costumam responder em até 1 dia

@Alexia-Soare já está trabalhando nisso.

Desde 17/9/2026.

Avaliação

Esta issue ainda não foi avaliada.

Descrição

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)

Linguagem predominante
PHP
Estrelas
108
Forks
29
Merge médio
1d 5h
PRs com merge (30d)
8

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de Codeinwp/visualizer

Todas as issues de Codeinwp/visualizer

Issues semelhantes

Mais issues de PHP

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.