Background
WorkflowValidationOptions currently accepts Set<string> for knownCommandNames and knownGuardNames. This means bootstrap-time validation of command and guard refs only works when callers can enumerate all registered names — i.e., when using the convenience commands / guards arrays in WorkflowModule.
When a caller supplies their own commandRegistry or guardRegistry (e.g., a DI-backed custom implementation), validation is skipped. Unresolved refs surface only when the event fires, as a runtime WorkflowError.
PR #18 documented this limitation for guards in docs/nestjs-integration.md (see commit 33040e2). Commands have the same shape but have not been called out yet.
Proposal
Extend WorkflowValidationOptions so each known-name option accepts either a Set<string> (today) or a predicate (name: string) => boolean. The validator branches on type:
Set<string> → set.has(name) (current behavior)(name) => boolean → call the predicate
Then in WorkflowModule, when commandRegistry / guardRegistry is supplied, pass (name) => registry.has(name) as the validation option. Both registry interfaces already expose has(name), so no new surface area is needed there.
This restores bootstrap-time validation parity between the array-based and registry-based forms, without requiring a getRegisteredNames() method on the registry interfaces.
Scope
packages/duraflows-core/src/validation/workflow-validator.ts — widen the option type and branch on itpackages/duraflows-nestjs/src/workflow.module.ts — wire the predicate when the custom registry path is taken (both forRoot and forRootAsync)- Tests for both code paths
- Update
docs/nestjs-integration.md to drop the limitation note added in 33040e2
Notes
Discovered during Copilot's review of PR #18 (event guards). Two of Copilot's comments touched this: one inline comment on docs/nestjs-integration.md:296, and one suppressed comment on workflow.module.ts:132.
Background
WorkflowValidationOptionscurrently acceptsSet<string>forknownCommandNamesandknownGuardNames. This means bootstrap-time validation of command and guard refs only works when callers can enumerate all registered names — i.e., when using the conveniencecommands/guardsarrays inWorkflowModule.When a caller supplies their own
commandRegistryorguardRegistry(e.g., a DI-backed custom implementation), validation is skipped. Unresolved refs surface only when the event fires, as a runtimeWorkflowError.PR #18 documented this limitation for guards in
docs/nestjs-integration.md(see commit 33040e2). Commands have the same shape but have not been called out yet.Proposal
Extend
WorkflowValidationOptionsso each known-name option accepts either aSet<string>(today) or a predicate(name: string) => boolean. The validator branches on type:Set<string>→set.has(name)(current behavior)(name) => boolean→ call the predicateThen in
WorkflowModule, whencommandRegistry/guardRegistryis supplied, pass(name) => registry.has(name)as the validation option. Both registry interfaces already exposehas(name), so no new surface area is needed there.This restores bootstrap-time validation parity between the array-based and registry-based forms, without requiring a
getRegisteredNames()method on the registry interfaces.Scope
packages/duraflows-core/src/validation/workflow-validator.ts— widen the option type and branch on itpackages/duraflows-nestjs/src/workflow.module.ts— wire the predicate when the custom registry path is taken (bothforRootandforRootAsync)docs/nestjs-integration.mdto drop the limitation note added in 33040e2Notes
Discovered during Copilot's review of PR #18 (event guards). Two of Copilot's comments touched this: one inline comment on
docs/nestjs-integration.md:296, and one suppressed comment onworkflow.module.ts:132.