Backfill mention trigger for existing Duo Developer installations

Problem

With the merge of !228817 (merged), the mention trigger was added to the developer/v1 foundational flow definition in ee/app/models/ai/catalog/foundational_flow.rb. The SyncFoundationalFlowsService is designed to add missing triggers on the next sync — it only creates triggers for event types that do not already exist.

However, the sync is only triggered when:

  • A new project is created
  • A group/namespace setting changes (e.g., duo_foundational_flows_enabled is toggled)
  • The CascadeSyncFoundationalFlowsWorker is explicitly enqueued

This means existing Duo Developer installations that were set up before !228817 (merged) was merged (2026-04-03) will not automatically receive the mention trigger unless one of the above events occurs for their project/group.

This was discovered when @thomas-schmidt and @mikolaj_wawrzyniak found that a project had only the assign trigger configured, even after the MR was merged. The project had to be manually updated.

Desired Outcome

All existing projects that have Duo Developer (developer/v1) configured should automatically receive the mention trigger added to their ai_flow_triggers records, without requiring any manual intervention or re-configuration.

Proposed Solution

Implement a background migration (batched background migration) or a post-deployment migration that:

  1. Identifies all projects that have:

    • An Ai::Catalog::ItemConsumer for the developer/v1 foundational flow
    • A corresponding Ai::FlowTrigger with the assign event type (event_type value 1)
    • No corresponding Ai::FlowTrigger with the mention event type (event_type value 0)

  2. For each such project, creates the missing mention trigger by:

    • Enqueuing Ai::Catalog::Flows::SyncProjectFoundationalFlowsWorker for the project, OR
    • Enqueuing Ai::Catalog::Flows::CascadeSyncFoundationalFlowsWorker for the root group of each affected project

The existing SyncFoundationalFlowsService#fetch_event_type_for_flow already handles deduplication correctly — it only creates triggers for event types that do not already exist — so re-running the sync is safe.

Technical Context

  • Foundational flow definition: ee/app/models/ai/catalog/foundational_flow.rb — developer/v1 now has both assign (value 1) and mention (value 0) in its triggers array
  • Sync service: ee/app/services/ai/catalog/flows/sync_foundational_flows_service.rb — handles deduplication via fetch_event_type_for_flow
  • Flow trigger model: ee/app/models/ai/flow_trigger.rb — EVENT_TYPES = { mention: 0, assign: 1, ... }
  • Worker: ee/app/workers/ai/catalog/flows/cascade_sync_foundational_flows_worker.rb

Related