Repository navigation
Validate name and id lengths on worker commands, not just on start #607
Description
Problem
Over-long names sent by a worker become database errors instead of validation errors.
POST /workflowsvalidates lengths:workflow_idup to 128,workflow_typeandtask_queueup to 255.- Commands a worker returns when completing a workflow task don't.
activity_type,queueand a child'sworkflow_typeare onlynullable|string, see also line 81, and the normalizer checks only that they're non-empty. - The columns are
VARCHAR(255):workflow_type,activity_typeandqueue. A longer value fails as a database error and leaves the workflow task to retry. - Signal, update and query names may be up to 256 bytes, and a limit of 0 disables the check. The name columns are 255 characters.
- The structural limits describe only the start endpoint.
Source-verified, not reproduced.
Acceptance criteria
- Every name and id a worker command or control-plane request can set is validated against its column length, and rejected with a typed
422that names the field. - Operation names are capped at 255, and the limit can't be disabled past the column size.
- Tests send over-long activity types, queues, child workflow types and signal names, and get validation errors.
- The structural limits page lists every name and id limit, including the 128-character Server cap on workflow ids against the 191-character column.
Activity
rmcdaniel commentedon Oct 21, 2026
Accepted as an API validation defect. Reproduce the published boundary first, then validate every writable identifier against its actual storage limit before mutation, including Unicode length behavior and operation names when the configurable limit is zero. Add exact-boundary and over-limit HTTP controls that verify typed 422s and unchanged task/history state. Keep the Server-specific workflow-id limit explicit in the structural limits documentation and all supported locales.
This follows the active critical PHP image publication (#591). Native parity remains coordinated through #325; no source or frozen-reference change is adopted by this intake.
rmcdaniel commentedon Nov 4, 2026
Server open-item pass, 2026-11-04.
Owner: Server for native route/command validation, Workflow for shared writable identifiers, Docs for limits. The next source inventory covers every persisted name/id at both start and completion, including queue, activity/child/workflow type and signal/update/query names.
Use actual column units and exact Unicode boundary controls rather than treating a configurable zero as permission to overflow storage. Invalid input must produce a typed422 before transaction/history/task changes; tests retain valid multibyte boundary and omitted/default cases. General/Workflow: confirm any portable name-limit differences before new shared vectors. No database error is reclassified as successful admission.
rmcdaniel commentedon Nov 4, 2026
Core storage/name fixture map requested in Server325/6643408164: public 2.20.3 NamespaceIdentity, typed SearchAttribute, search value filters, namespace start controls, schedule namespace/ID controls and memo/search structural limits. Please verify each mode’s actual grammar/storage bound from those sources; PHP class identifiers, namespace IDs, portable names, memo keys and search keys are not one interchangeable rule. 853’s accepted decision explicitly preserves mode-specific/legacy grammar and typed canonical-size refusal. Workflow will provide one field/unit table from its source inventory; no blanket native equality or renamed/normalized old key is claimed. Server owns its distinct explicit child-ID and deleted schedule-ID policy proposals, preserving current refusal until reviewed.
Delivery evidence remains the exact public Core 2.20.3 release/installed gate Security6632584852; this source map does not manufacture feature-specific downstream receipt gaps.
rmcdaniel commentedon Nov 11, 2026
Triage 2026-11-11: applies to native (completion_rules.rs has no 255 max on activity_type/queue/workflow_type). Next: max(255) with 422 boundary tests. Owner: server.