Developer foundational flow keeps stale generic merge_request trigger, causing rogue flow runs on MR events

Summary

Projects whose Developer foundational flow (developer/v1) was synced between the deploy of !249084 (merged) (milestone 19.3) and the deploy of !250220 (merged) (2026-09-07) retain a stale, generic merge_request trigger row (Ai::FlowTrigger event type 6) with an empty action filter.

Foundational-flow trigger synchronization is create-only (it adds missing events but never prunes obsolete ones), so the fix in !250220 (merged) — which removed EVENT_TYPES[:merge_request] from the Developer defaults — does not clean up these rows for existing projects.

Result: the Developer flow starts on arbitrary merge request events (observed: MR opened / "marked ready", and MR approved) without the prompt/command context it receives when explicitly mentioned or assigned, so the session has no task and hangs / is blocked from processing. The trigger UI also only shows "Merge request" without indicating which MR action applies (see also #627346).

Steps to reproduce

  1. On a project created during the affected window (e.g. around 2026-08-20 on GitLab.com), enable the Duo Developer foundational flow.
  2. Check AI > Triggers: the auto-created Developer trigger contains a generic "Merge request" event with no action selected.
  3. Open an MR (marked ready) or approve it.
  4. A Developer session is started with no goal/prompt and stalls.

Example Project

https://gitlab.com/gitlab-org/developer-relations/contributor-success/bridge-gitlab-com/-/merge_requests/24 — the Developer flow triggered when the MR was opened ("marked ready") and again when it was approved. The project was created around 2026-08-20.

What is the current bug behavior?

  • A stale merge_request trigger row persists on the Developer flow for projects synced in the affected window.
  • With an empty action filter, the row effectively matches all supported MR events, so Developer runs on MR open/ready/approve.
  • Developer is not designed to run from a bare MR trigger: without the goal/prompt carried by an assign or mention, the session doesn't know what to do and hangs.

What is the expected correct behavior?

  • The Developer foundational flow only has assign and mention triggers (as on master after !250220 (merged)).
  • No Developer sessions are started from bare MR events.
  • The trigger UI indicates which MR action applies (tracked separately in #627346).

Root cause

  1. !249084 (merged) (stack: !249081 (merged) backend allowlist, !249082 (merged) worker + feature flag) added EVENT_TYPES[:merge_request] to the Developer flow trigger defaults to drive a merged-MR flow via the legacy MergedEvent. It caused no behavior change at the time because the related feature flags were default-off.
  2. The auto-created trigger row stores the bare merge_request event type with an empty action filter, which effectively matches all MR events instead of only merged.
  3. !250220 (merged) removed EVENT_TYPES[:merge_request] from the Developer defaults (the merged-MR flow now uses MergeRequests::MergedCloudEvent) and was deployed on 2026-09-07. However, SyncFoundationalFlowsService is create-only, so every namespace that synced the Developer flow during the affected window keeps the rogue trigger row indefinitely.

Affected scope

  • GitLab.com: projects/namespaces that synced the Developer foundational flow between the !249084 (merged) deploy (~19.3) and the !250220 (merged) deploy (2026-09-07).
  • Self-managed / Dedicated: any 19.3.x installation, since !249084 (merged) shipped in 19.3; those customers keep accumulating the stale trigger until both the code fix and a cleanup are backported.

Proposed fix

  1. Scoped data cleanup (batched post-deployment migration, so it also reaches self-managed/Dedicated on upgrade):
    • Target only system/auto-created triggers belonging to the Developer foundational flow (item consumer referencing developer/v1) created within the affected window.
    • Remove only the merge_request event type (EVENT_TYPES[:merge_request] = 6) from the trigger's event_types; preserve assign/mention.
    • Delete the row only if no event types remain.
    • Do not touch user-created triggers that intentionally use MR events.
    • Do not reuse the existing "backfill empty MR filters to approved" migration for this — it would still run Developer on every approval and applies broadly to all MR triggers.
  2. Backport to 19.3: cherry-pick the narrow default change from !250220 (merged) (removal of EVENT_TYPES[:merge_request] from the Developer defaults) to 19-3-stable-ee, together with the cleanup migration, so self-managed/Dedicated customers stop accumulating new stale rows. A full cherry-pick of !250220 (merged) is likely inappropriate since it also introduces the MergedCloudEvent path targeted at 19.4.

Workaround (available now)

In each affected project: AI > Triggers → delete the rogue Merge request trigger on the Developer flow (keeping the assign/mention triggers).

References

Filed by GitLab Duo on behalf of @junminghuang from an internal Slack discussion (reported by @leetickett-gitlab). Created confidential by default per the SAFE framework; the content appears non-sensitive (all references are public), so feel free to make it public.