https://sonarly.com/issue/36114?type=bug
Users who attempt to duplicate an incomplete workflow (one with steps but no trigger configured) receive an unhandled error. The backend strictly requires a trigger to be present in the source version before duplication, but the frontend offers the duplicate action regardless of whether a trigger exists.
Fix: ## Code fix: `workflow-version.workspace-service.ts`
Removed `assertWorkflowVersionTriggerIsDefined(sourceVersion)` and `assertWorkflowVersionHasSteps(sourceVersion)` from the `duplicateWorkflow` method. These guards are appropriate for *activating* a workflow (handled in `workflow-trigger.workspace-service.ts`) but not for duplicating one — a duplication always produces a new DRAFT, so copying an incomplete draft (missing trigger or steps) into another draft is semantically valid and was already handled correctly by the surrounding code:
- `sourceVersion.trigger` null → `remappedTrigger = undefined` (already guarded with `isDefined(newTrigger)`)
- `sourceVersion.steps` null/empty → `for (const step of sourceVersion.steps ?? [])` (already guarded with `?? []`)
The imports for both utilities are preserved because they continue to be used in `createDraftFromWorkflowVersion`.
## Monitoring fix: `workflow-version.resolver.ts`
Added `WorkflowTriggerGraphqlApiExceptionFilter` to the `@UseFilters` decorator on `WorkflowVersionResolver`. This filter converts `WorkflowTriggerException` into a `UserInputError` (a GraphQL-level validation error), which prevents it from being sent to Sentry. This matches the existing pattern in `workflow-builder.resolver.ts` and `workflow-trigger.resolver.ts`, which already apply this filter. Without it, any future `WorkflowTriggerException` thrown from `createDraftFromWorkflowVersion` or `updateWorkflowVersionPositions` would also produce noisy Sentry events.
Sonarly Claude Code
2df52785ba