Crash on Bloomz site (logging bridge)

[noelsaw1]

Message Uncaught TypeError: Hypercart_Logger:: info(): Argument #2 ($message) must be of type string, array given, called in /nas/ content/live/bloomzhemp/wp-content/mu-plugins/hypercart-query- guard.php on line 1124 and defined in /nas/content/live/bloomzhemp/ wp-content/plugins/Hypercart-Helper-WP-plugin/includes/class- hypercart-logger.php:96 Stack trace: #0 /nas/content/live/ bloomzhemp/wp-content/mu-plugins/hypercart-query-guard.php (1124): Hypercart_Logger:: info('query_guard', Array) #1 /nas/content/live/ bloomzhemp/wp-content/mu-plugins/hypercart-query-guard.php (803): Hypercart_Query_Guard:: log('info', Array) #2 /nas/content/live/ bloomzhemp/wp-content/mu-plugins/hypercart-query-guard.php(471): Hypercart_Query_Guard: :maybe_log_throttle_events (Array) #3 /nas/ content/live/bloomzhemp/wp-content/mu-plugins/hypercart-query- guard. php (340): Hypercart_Query_Guard::get_throttle_decision () #4 / nas/content/live/bloomzhemp/wp-includes/class-wp-hook.php (341): Hypercart_Query_Guard:: filter_queue_runner_concurrent_batches (1) #5 /nas/content/live/bloomzhemp/wp-includes/plugin.php(205): WP_Hook- >apply_filters(1, Array) #6 /nas/content/live/bloomzhemp/wp-content/ plugins/woocommerce/packages/action-scheduler/classes/abstracts/ ActionScheduler_Abstract_QueueRunner. php (251) : apply_filters('action_schedule...', 1) #7 /nas/content/live/ bloomzhemp/wp-content/plugins/woocommerce/packages/action-scheduler/ classes/abstracts/ActionScheduler_Abstract_QueueRunner.php (260): ActionScheduler_Abstract_QueueRunner- >get_allowed_ _concurrent_batches () #8 /nas/content/live/bloomzhemp/ wp-content/plugins/woocommerce/packages/action-scheduler/classes/ ActionScheduler_ListTable-php (375): ActionScheduler_Abstract. _QueueRunner- ›has_maximum_concurrent_batches () #9 /nas/content/live/bloomzhemp/ wp-content/plugins/woocommerce/packages/action-scheduler/classes/ abstracts/ActionScheduler _Abstract_ListTable-php (776):

[noelsaw1]

The stack trace fragment was enough to work from once paired with the logging design in ARCHITECTURE.md. The crash was not in the throttle logic itself; it was in the logging bridge in hypercart-query-guard.php, where structured payload arrays were being passed directly into Hypercart_Logger::info/error/warn even though that logger expects its second argument to be a string. That matches your stack exactly: the Action Scheduler admin page triggered a throttle decision, throttle logging ran, and the logger type check threw before the page could render.

I patched hypercart-query-guard.php so the plugin keeps payloads structured internally but JSON-serializes them before calling Hypercart_Logger. I also added a regression test in LoggingTest.php that models a string-only Hypercart_Logger signature, and I updated the logging notes in ARCHITECTURE.md and README.md so the docs reflect the real bridge behavior.

[noelsaw1]

Fix here: #38

[noelsaw1]

1. Why this was a hard crash, not a degraded log line
   Several things stacked up:

array → string is never coercible. PHP's coercive (non-strict) mode will quietly convert int/float/bool/numeric-string scalars to satisfy a typehint. It will never coerce an array to a string. So Hypercart_Logger::info('query_guard', [...]) throws a TypeError — and nothing in the call chain catches Throwable. An uncaught Error → fatal → HTTP 500.

It fired inside a WordPress filter, deep in someone else's render path. The stack shows ActionScheduler_ListTable → has_maximum_concurrent_batches() → apply_filters('action_scheduler_queue_runner_concurrent_batches', 1) → our filter_queue_runner_concurrent_batches(). The throttle's decision succeeded; it was the attempt to log that decision that killed the request. Observability code crashing the thing it observes is the worst failure shape — a benign "we saw load" event became an outage.

It's an MU-plugin. wp-content/mu-plugins/hypercart-query-guard.php cannot be deactivated from the admin UI. An admin who hits the fatal can't click "deactivate" to recover — they need filesystem/SFTP access. That turns a bug into an operational incident.

The hot path made it reliably reproducible. get_allowed_concurrent_batches() runs both on the AS admin ListTable and in the web queue runner, so the same fatal could wedge background job processing, not just the admin screen.

It was latent. It only triggers when (a) the throttle is in a mode that emits events and (b) the installed Hypercart_Logger happens to typehint string. The old test stub was untyped, so the suite stayed green while production fatalled — an integration-environment-specific bug invisible to unit tests until a specific plugin-combo + mode went live.

2. Anything else like it?
   The bug class: a contract mismatch at a boundary with code this repo doesn't version-control, guarded only by existence checks (class_exists/method_exists/function_exists prove presence, never signature).

I scanned every such boundary. Findings:

Boundary Status
Hypercart_Logger::error/info/warn Fixed — in both hypercart-query-guard.php:1120 and class-hcqg-mutex-guard.php:408
$action->get_priority() / $new_action->set_priority() (:731) Safe today. Same method_exists-only guard pattern, but the call is arg-compatible by construction (get_priority() returns the int set_priority() wants) and AS's interface is stable. Would fatal identically if a forked/future AS changed the signature.
$schedule->is_recurring() (:613) Safe — stable AS interface, no args, bool context.
$wpdb->hcqg_is_active() (:178) Safe — calls our own db.php drop-in, no args, bool context.
mysqli_query / mysqli_error (load-monitor:336) Already hardened — the changelog's instanceof mysqli fix covers this.
apcu_*, openssl_random_pseudo_bytes, get_current_user_id Safe — stable core/extension signatures.
Good news on the inbound side: our hook callbacks — filter_queue_runner_batch_size/time_limit/concurrent_batches, maybe_defer_action_before_execute — deliberately have untyped parameters and cast internally ((int) $batch_size). So the inverse of the logger bug (AS feeding us an unexpected type) can't fatal. That's the right defensive posture, already in place.

The remaining array-typehinted internal methods — log(array $payload), maybe_log_throttle_events(array $decision), apply_throttle_value(..., array $decision), defer_count_key(..., array $args, ...) — are only ever reached with internally-constructed data today. The throttle decision is built in-house and not round-tripped through a public apply_filters, so no third party can inject a non-array. They're safe now, but they're the same shape of risk if a public decision filter is ever added.

Bottom line: the logger bug was the only live-dangerous instance, and it's fixed in both call sites. The AS priority API shares the guard pattern but is currently arg-safe. And — correcting my earlier review — the test gap I flagged is now closed: test_log_dispatches_json_to_string_only_logger_end_to_end (LoggingTest.php:83) shells out to tests/fixtures/string-logger-integration.php, which defines a string-typed Hypercart_Logger and exercises the real log() path end-to-end. That's exactly the regression test this bug warranted.

3. Codebase size
   Tracked PHP: 4,110 lines across 12 files.

Production: ~2,528 lines — hypercart-query-guard.php (1,224), class-hcqg-mutex-guard.php (480), class-hcqg-load-monitor.php (453), db.php (226), class-hcqg-priority-registry.php (145)
Tests: ~1,582 lines — 6 test files + a 325-line bootstrap + the 81-line fixture. Roughly a 0.6:1 test-to-production ratio.
On disk the repo is 8.4M, but that's almost entirely vendor/ (7.5M, PHPUnit) and .git/ (480K) — the actual source is ~80KB. Plus the docs (ARCHITECTURE.md, README.md, CHANGELOG.md, AGENTS.md). It's a compact, single-purpose MU-plugin.