Summary
wfctl validate accepts step.conditional routes whose YAML keys parse as booleans, but the runtime step factory only accepts map[string]any route maps. A route like true: next-step validates successfully, then the Workflow server fails during pipeline configuration with routes map is required and must not be empty.
Reproduction
From workflow/cmd/wfctl:
# This config contains conditional route keys written as unquoted true:
# routes:
# true: allow-update
GOWORK=off go run . validate --skip-unknown-types /tmp/scenario90-unquoted-true.yaml
Observed validator output:
PASS /tmp/scenario90-unquoted-true.yaml (9 modules, 1 workflows, 0 triggers)
Runtime failure from the same config in Scenario 90 Docker launch:
Setup error: failed to build engine: failed to build workflow: failed to configure pipelines: pipeline "authz-roles-add": step "route-by-authz-roles-update" (type step.conditional): conditional step "route-by-authz-roles-update": 'routes' map is required and must not be empty
The immediate fix in Scenario 90 was quoting boolean-looking route keys:
routes:
'true': allow-update
Expected Behavior
wfctl validate should fail when step.conditional.config.routes contains non-string YAML keys or keys that YAML decodes as booleans/numbers/null. It should point at the route key and suggest quoting it, e.g. 'true': allow-update.
Why It Matters
This is a runtime-only config failure that the validator should catch before Docker/server launch. It is easy to hit because conditionals commonly route on boolean-looking values such as true/false.
Notes
The runtime constructor in module/pipeline_step_conditional.go expects routesRaw, _ := config["routes"].(map[string]any), so YAML-decoded map[any]any/non-string-key maps do not survive into runtime configuration as valid routes. The validator appears to allow the shape before that runtime conversion failure.
Summary
wfctl validateacceptsstep.conditionalroutes whose YAML keys parse as booleans, but the runtime step factory only acceptsmap[string]anyroute maps. A route liketrue: next-stepvalidates successfully, then the Workflow server fails during pipeline configuration withroutes map is required and must not be empty.Reproduction
From
workflow/cmd/wfctl:Observed validator output:
Runtime failure from the same config in Scenario 90 Docker launch:
The immediate fix in Scenario 90 was quoting boolean-looking route keys:
Expected Behavior
wfctl validateshould fail whenstep.conditional.config.routescontains non-string YAML keys or keys that YAML decodes as booleans/numbers/null. It should point at the route key and suggest quoting it, e.g.'true': allow-update.Why It Matters
This is a runtime-only config failure that the validator should catch before Docker/server launch. It is easy to hit because conditionals commonly route on boolean-looking values such as
true/false.Notes
The runtime constructor in
module/pipeline_step_conditional.goexpectsroutesRaw, _ := config["routes"].(map[string]any), so YAML-decodedmap[any]any/non-string-key maps do not survive into runtime configuration as valid routes. The validator appears to allow the shape before that runtime conversion failure.