Workflow triggers silently stop firing after 2.37 → 2.39.5 upgrade: workflowAutomatedTrigger keeps legacy workflow IDs not present in core.workflow

Bug Description

After upgrading a self-hosted instance from v2.37.0 to v2.39.5, no workflow trigger fires any more — neither CRON nor DATABASE_EVENT. Workflows still display as ACTIVE in the UI and no error is shown to the user.

The upgrade migrated workflows into the core schema and assigned new primary keys, but the rows in workspace_*."workflowAutomatedTrigger" still reference the old workflow IDs.

Same workflow, both tables:

table	id	lastPublishedVersionId
workspace_*."workflow"	4966e027-…	2c6e26d4-…
core."workflow"	a12198e0-…	2c6e26d4-…

Note the version ID is preserved but the workflow ID is not. All core."workflow" rows were created at the upgrade timestamp (2026-09-12T09:43:01.820Z).

The stranded trigger row:

{
  "type": "CRON",
  "settings": { "pattern": "0 0 */1 * *" },
  "workflowId": "4966e027-…"
}

Every night the trigger fires correctly and then dies on the lookup:

LOG   [WorkflowCronTriggerCronJob] Enqueuing WorkflowTriggerJob for workflow 4966e027-… in workspace b1f9491b-…
LOG   [BullMQDriver] Processing job 92 with name WorkflowTriggerJob on queue workflow-queue
ERROR [WorkflowTriggerJob] Core workflow version 25b7f810-… not found in workspace b1f9491b-…
      at WorkflowTriggerJob.handleFromCore (.../workflow-trigger.job.js:61:17)
LOG   [BullMQDriver] Job 92 with name WorkflowTriggerJob processed on queue workflow-queue in 0.98ms

The job is marked processed, so nothing surfaces as a failure. No workflowRun row is created. From the user's point of view the workflow simply never runs.

The poller reads triggers from the legacy workspace_*."workflowAutomatedTrigger" table, while handleFromCore resolves against core. core has no %trigger% table at all — triggers now live in core."workflowVersion".triggers (jsonb).

Impact: all automation stops silently after upgrade. No error, no UI indication, and workflows still show as ACTIVE. We only found it because a daily cleanup workflow hadn't run for a week.

Expected behavior

The upgrade should repoint workflowAutomatedTrigger rows at the new core workflow IDs (or migrate them into core."workflowVersion".triggers), so existing triggers keep firing.

Failing that, a trigger resolving to a non-existent workflow should be logged as an error / marked failed rather than silently marked processed.

Technical inputs

• Version: twentycrm/twenty:v2.39.5, self-hosted on Kubernetes, upgraded from v2.37.0
• Core migrations fully applied; all 423 core."upgradeMigration" rows completed, no failures
• Affects both CRON and DATABASE_EVENT triggers (5 stranded rows in our instance)
• Workaround: deactivating and re-activating each workflow in the UI re-registers the trigger correctly and restores firing
• Possibly related: #25679 (add coreWorkflowId to core workflow versions), #25680 (Skip workflow status update when the workflow no longer exists)