You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
PHP Server health returns 500 on MariaDB (ONLY_FULL_GROUP_BY in task queue build-id snapshot) #569
On MariaDB, GET /api/system/health returns 500 once a namespace has an open workflow task in a task queue with registered workers.
Evidence
Published PHP Server 2.5.14 (ghcr.io/durable-workflow/server@sha256:28fa0f39…), DB_CONNECTION=mysql against MariaDB 10.11 with the image's default SQL mode. The operator-metrics scenario on #562 (one run, one activity) returns 200 for operator-metrics at every stage. health returns 200 until the activity is scheduled, then 500 at every later stage:
SQLSTATE[42000]: Syntax error or access violation: 1055 '<db>.workflow_tasks.compatibility' isn't in GROUP BY
select `workflow_tasks`.`status`, COALESCE(NULLIF(TRIM(workflow_tasks.compatibility), ''), NULLIF(TRIM(workflow_runs.compatibility), '')) as effective_compatibility, COUNT(*) as task_count
from `workflow_tasks` left join `workflow_runs` on `workflow_runs`.`id` = `workflow_tasks`.`workflow_run_id`
where ... group by `workflow_tasks`.`status`, COALESCE(NULLIF(TRIM(workflow_tasks.compatibility), ''), NULLIF(TRIM(workflow_runs.compatibility), ''))
The same scenario passes on MySQL 8.0, MySQL 8.4, PostgreSQL 17 and SQLite. MariaDB does not treat the repeated COALESCE expression in GROUP BY as covering the selected one under ONLY_FULL_GROUP_BY.
The query is still on current main, in App\Support\TaskQueueBuildIdRolloutSnapshot::pendingWorkflowTaskCountsForTaskQueue.
Expected
The health document answers on MariaDB as on the other supported databases.
Native
The native server answers 200 at every stage on MariaDB. The shared operator-metrics fixture accepts this published PHP 500 only for PHP on MariaDB, and only after an activity exists, until a published PHP release no longer has it.
This still reproduces on stock published Server 2.11.7 / Core 2.15.7, immutable amd64 image sha256:be7c2288ff935396262d743590530b204fac11b76582e56a525cc81a8da840d3, against real MariaDB 10.11.19 with default SQL mode. The October 29 operator profile returns 200 for metrics with the correct namespace in every stage, while /api/system/health returns 500 at activity-scheduled, activity-running, activity-retrying and completed stages.
The request-correlated application error at 19:52:51 UTC is the same MariaDB 1055 failure: workflow_tasks.compatibility is not covered by the COALESCE GROUP BY expression in the task-queue build-ID snapshot. The unchanged conformance case accepts its existing documented PHP/MariaDB disposition when supplied the truthful database image hint; that is qualification of the known behavior, not a health repair.
This is separate from #825's historical approved-update investigation and its corrected fixture-envelope differences. No new namespace-isolation issue follows from the health response lacking a namespace during the 500. Keep this health defect open through a qualified published PHP correction.
General owns final-PHP known-defect disposition; Server owns the native MariaDB fixture boundary. The retained real MariaDB10.11.19/Server2.11.7 failure is the precise1055 GROUPBY defect. Native200 coverage and PHP’s narrow documented500 alternative are distinct outcomes.
General: retain the limitation for final2.11.8 or explicitly close as not planned under the no-PHP-release stop, unless a newer immutable corrected-reference receipt already exists. Server will not remove that PHP exception based on native success, nor infer namespace leakage from an error response. No new PHP SQL/source/release or database test starts here.
Closing: PHP Server receives no further releases. Native runs the same GROUP BY shape in task_queue_build_ids.rs but does not enable ONLY_FULL_GROUP_BY; if that changes, harden the query then.
Activity
Accept published PHP's MariaDB health failure in the operator metrics…
rmcdaniel commentedon Oct 29, 2026
This still reproduces on stock published Server 2.11.7 / Core 2.15.7, immutable amd64 image
sha256:be7c2288ff935396262d743590530b204fac11b76582e56a525cc81a8da840d3, against real MariaDB 10.11.19 with default SQL mode. The October 29 operator profile returns 200 for metrics with the correct namespace in every stage, while/api/system/healthreturns 500 at activity-scheduled, activity-running, activity-retrying and completed stages.The request-correlated application error at 19:52:51 UTC is the same MariaDB 1055 failure:
workflow_tasks.compatibilityis not covered by the COALESCE GROUP BY expression in the task-queue build-ID snapshot. The unchanged conformance case accepts its existing documented PHP/MariaDB disposition when supplied the truthful database image hint; that is qualification of the known behavior, not a health repair.This is separate from #825's historical approved-update investigation and its corrected fixture-envelope differences. No new namespace-isolation issue follows from the health response lacking a namespace during the 500. Keep this health defect open through a qualified published PHP correction.
rmcdaniel commentedon Nov 4, 2026
Server open-item pass, 2026-11-04.
General owns final-PHP known-defect disposition; Server owns the native MariaDB fixture boundary. The retained real MariaDB10.11.19/Server2.11.7 failure is the precise1055 GROUPBY defect. Native200 coverage and PHP’s narrow documented500 alternative are distinct outcomes.
General: retain the limitation for final2.11.8 or explicitly close as not planned under the no-PHP-release stop, unless a newer immutable corrected-reference receipt already exists. Server will not remove that PHP exception based on native success, nor infer namespace leakage from an error response. No new PHP SQL/source/release or database test starts here.
rmcdaniel commentedon Nov 11, 2026
Closing: PHP Server receives no further releases. Native runs the same GROUP BY shape in task_queue_build_ids.rs but does not enable ONLY_FULL_GROUP_BY; if that changes, harden the query then.