Problem
The three error constructors in pkg/workflow/workflow_errors.go are inconsistent in how they guard their log calls:
NewOperationError (line 118): correctly guards with if errorHelpersLog.Enabled() { ... }NewValidationError (line 66): unconditionally calls errorHelpersLog.Printf(...)NewConfigurationError (line 171): unconditionally calls errorHelpersLog.Printf(...)
NewValidationError is called from at least 40 call sites across validation files (expression syntax, network firewall, sandbox, features, runtime, cache, concurrency, etc.) — often in hot validation loops. Every call unconditionally evaluates the format string arguments and invokes the logger, even when debug logging is disabled.
Current Code
// NewValidationError — no guard (line 64-73)
func NewValidationError(field, value, reason, suggestion string) *WorkflowValidationError {
errorHelpersLog.Printf("Creating validation error: field=%s, reason=%s", field, reason)
...
}
// NewOperationError — correctly guarded (line 117-130)
func NewOperationError(...) *OperationError {
if errorHelpersLog.Enabled() {
errorHelpersLog.Printf("Creating operation error: ...")
}
...
}Recommendation
Apply the same guard pattern to NewValidationError and NewConfigurationError:
func NewValidationError(field, value, reason, suggestion string) *WorkflowValidationError {
if errorHelpersLog.Enabled() {
errorHelpersLog.Printf("Creating validation error: field=%s, reason=%s", field, reason)
}
...
}
func NewConfigurationError(configKey, value, reason, suggestion string) *ConfigurationError {
if errorHelpersLog.Enabled() {
errorHelpersLog.Printf("Creating configuration error: configKey=%s, reason=%s", configKey, reason)
}
...
}Severity
- Medium — unnecessary CPU/memory work on every validation error construction; affects 40+ call sites in performance-sensitive compilation paths
Validation
Generated by Sergo - Serena Go Expert · ● 388.4K · ◷
Problem
The three error constructors in
pkg/workflow/workflow_errors.goare inconsistent in how they guard their log calls:NewOperationError(line 118): correctly guards withif errorHelpersLog.Enabled() { ... }NewValidationError(line 66): unconditionally callserrorHelpersLog.Printf(...)NewConfigurationError(line 171): unconditionally callserrorHelpersLog.Printf(...)NewValidationErroris called from at least 40 call sites across validation files (expression syntax, network firewall, sandbox, features, runtime, cache, concurrency, etc.) — often in hot validation loops. Every call unconditionally evaluates the format string arguments and invokes the logger, even when debug logging is disabled.Current Code
Recommendation
Apply the same guard pattern to
NewValidationErrorandNewConfigurationError:Severity
Validation
go test ./pkg/workflow/...passespkg/workflow/processing_benchmark_test.go) show no regression