https://sonarly.com/issue/30633?type=bug
When a workflow is deleted while an automated trigger (e.g. DATABASE_EVENT) is in-flight or already enqueued, the BullMQ job fires and reaches createWorkflowRun(). That method successfully finds the workflow version (not yet soft-deleted at that point), but then queries for the parent workflow record WITHOUT withDeleted: true. Since the workflow was already soft-deleted by the POST-QUERY hook, the lookup returns null, throwing WorkflowRunException("Workflow id is invalid", WORKFLOW_RUN_INVALID).
Fix: Added `withDeleted: true` to the workflow `findOne` query in `createWorkflowRun()` (workflow-run.workspace-service.ts line 82-85).
This query fetches the parent workflow to get its name for the workflow run display name (e.g., `#3 - My Workflow`) and to get the last run count. When a workflow is soft-deleted (deletedAt set) but its automated trigger has already enqueued a BullMQ job, the run creation races with the deletion cascade. The workflow is soft-deleted first (invisible to normal queries), but versions and triggers are cascaded in a POST-QUERY hook afterward — creating a window where createWorkflowRun finds the version but not the workflow.
By adding `withDeleted: true`, the query includes soft-deleted records, matching the pattern already used in workflow-common.workspace-service.ts (lines 271, 295, 375) for similar cross-entity lookups during deletion flows. The workflow data is only used for the display name — there is no functional reason to exclude soft-deleted workflows here.
Sonarly Claude Code
2e246b86c6