Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Action Scheduler async queue crashes on WordPress 5.3 with `wpdb::db_server_info()` error

Abierto
  • ¿Algo no está bien?
#1,361 4 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@girishpanchal30 ya está trabajando en esto.

Desde el 12/8/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

bug-report bug-report-triage crash-report

Summary

Visualizer's background Action Scheduler queue can terminate with an uncaught Call to undefined method wpdb::db_server_info() error during an AJAX request on WordPress 5.3.

Expected behavior: Scheduled actions are claimed and processed without a fatal error on supported WordPress environments.

Actual behavior: The async queue runner reaches the database claim path and throws before processing the batch.

Impact: Automatic background processing is interrupted for the affected site and request.

Customer context

  • Product / area: Visualizer background auto-sync / bundled Action Scheduler
  • Version: 4.0.7
  • Environment: WordPress 5.3.21, PHP 7.4.33
  • Integration / third party: Bundled woocommerce/action-scheduler 3.9.3
  • Reported error / symptom: Error: Call to undefined method wpdb::db_server_info() during an AJAX queue-runner request
  • Impact: 14 telemetry occurrences across one distinct site between 2026-07-31 20:01 UTC and 23:35 UTC.

Reproduction notes

  1. Install Visualizer 4.0.7 on WordPress 5.3.21 with PHP 7.4.33.
  2. Trigger the Action Scheduler async queue runner through its AJAX request path.
  3. When ActionScheduler_DBStore::claim_actions() checks database locking support, the reported production run throws Call to undefined method wpdb::db_server_info().

Reproduction is supported by the production stack trace; no local runtime reproduction was performed because the bundled vendor/ directory is absent from this checkout.

Diagnosis

Conclusion

Production telemetry provides a direct stack trace from Visualizer's bundled Action Scheduler path: ActionScheduler_DBStore::db_supports_skip_locked() throws because it calls wpdb::db_server_info() on WordPress 5.3.21. The Visualizer 4.0.7 release locks Action Scheduler 3.9.3, and an inspected copy of that exact dependency version contains the unconditional call. This is a confirmed compatibility defect in the shipped dependency path, not Themeisle SDK code.

Where this likely occurs
  • vendor/woocommerce/action-scheduler/classes/data-stores/ActionScheduler_DBStore.php — ActionScheduler_DBStore::db_supports_skip_locked() lines 1038-1042 in the inspected Action Scheduler 3.9.3 copy; it obtains $wpdb->db_version() and then unconditionally calls $wpdb->db_server_info(). Telemetry identifies the equivalent bundled Visualizer file at line 1041.
  • composer.lock — Action Scheduler package record lines 181-221 locks version 3.9.3 at reference c58cdbab17651303d406cd3b22cf9d75c71c986c; v4.0.7 contains the same lock entry.
  • index.php — Visualizer bootstrap lines 148-157 loads vendor/autoload.php and the bundled Action Scheduler entry point when present.
  • classes/Visualizer/Plugin.php — Visualizer_Plugin::VERSION line 31 identifies the checked release as 4.0.7.
  • Git commit bc14d4b8acebefc167ef51601a4898fb302d0b71 introduced the Action Scheduler dependency and bootstrap under “Replace WP-Cron with Action Scheduler for reliable auto-sync”; the telemetry is from the later v4.0.7 tag.
Engineering notes
  • The error occurs while ActionScheduler_DBStore::claim_actions() evaluates whether SKIP LOCKED is supported, before the queue batch is processed.
  • The reported request context is AJAX and the stack continues through ActionScheduler_AsyncRequest_QueueRunner, matching Visualizer's bundled async dependency loading path.
  • WordPress core source was not present in the inspected workspace, so the absence of wpdb::db_server_info() on WordPress 5.3.21 is established by the production exception rather than a local core-source check.
  • The telemetry names no Themeisle SDK frame and explicitly marks the crash as outside SDK code.
Test coverage status

tests/test-schedule.php covers Visualizer scheduled/background import behavior, including an unauthenticated background invocation, but does not exercise Action Scheduler queue claiming or the db_supports_skip_locked() compatibility branch. No relevant Action Scheduler compatibility coverage was found during inspection.

What to verify or explore next
  • Reproduce the async queue-runner request with Visualizer 4.0.7, WordPress 5.3.x, and the bundled dependency.
  • Check the Action Scheduler version range supported by Visualizer's released WordPress compatibility policy.
  • Run the existing scheduler test suite and a queue-claim integration scenario against WordPress 5.3.x and currently supported WordPress versions.
Unknowns / follow-up
  • Telemetry covers one site, so the prevalence across other WordPress 5.3 installations is unknown.
  • The customer site's database engine and version were not included in the crash report.

Confidence

Confidence: 98/100

Production telemetry records 14 AJAX crashes in Visualizer 4.0.7 on WordPress 5.3.21, and the release locks the stack frame's Action Scheduler 3.9.3 dependency whose inspected db_supports_skip_locked() implementation directly calls the unavailable wpdb::db_server_info() method.

Crash telemetry
Occurrences 14
Distinct sites 1
First seen 2026-07-31 20:01 UTC
Last seen 2026-07-31 23:35 UTC
Crash location product:vendor/woocommerce/action-scheduler/classes/data-stores/ActionScheduler_DBStore.php:1041
Request context ajax
Inside Themeisle SDK no
Product versions 4.0.7
WP versions 5.3.21
PHP versions 7.4.33
SDK versions 3.3.57

Source: automated crash report — visualizer, fingerprint 28da1fdfc9908565fa3b3beaadc83288
Generated by bug-report-triage (ID: bug-report-triage_6a6d8b7c4b6548.22981080)

Lenguaje dominante
PHP
Estrellas
108
Forks
29
Merge medio
1 d 5 h
PR fusionados (30 d)
8

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Codeinwp/visualizer

Todos los issues de Codeinwp/visualizer

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.