Remove bail_flow_trigger_on_unsupported_resource feature flag

Marc Shawrequested to merge
remove-bail-flow-trigger-on-unsupported-resource-ff into master

This removes the bail_flow_trigger_on_unsupported_resource feature flag. It has been enabled for 100 percent of GitLab.com since 2026-09-08 with no problems reported, so the resource-type check in Ai::FlowTriggers::RunService now always runs instead of being gated by a flag.

Detailed context for AI agents

What does this MR do and why?

Ai::FlowTriggers::RunService checks, before starting a Duo Agent Platform flow, whether the foundational flow supports the resource type that triggered it. For example, a flow that only supports merge requests should not start when triggered on an issue. This check lived behind the bail_flow_trigger_on_unsupported_resource feature flag.

When the flag was off, the check was skipped and the run started anyway. When the flag was on, the run bailed with the error "cannot be triggered for a <ResourceClass> resource", reason :unsupported_resource_type, and no workflow was created.

The flag was introduced in !252325 (merged). It was enabled on staging and for the code-review-playground project on 2026-09-08, then enabled for 100 percent of GitLab.com the same day. It has stayed on since, with no problems reported on the rollout issue. This MR makes that behavior permanent by removing the flag.

File changes:

  • Deleted ee/config/feature_flags/gitlab_com_derisk/bail_flow_trigger_on_unsupported_resource.yml, the flag definition.

  • ee/app/services/ai/flow_triggers/run_service.rb: removed the return true if Feature.disabled?(...) early return from supported_resource?, so the check always runs.

  • ee/app/models/ai/catalog/foundational_flow.rb: removed a 3-line comment above resolve_additional_context_for that explained the method was deliberately not gated by the flag. No code change in this file, just a stale comment.

  • ee/spec/services/ai/flow_triggers/run_service_spec.rb: removed two contexts that stubbed the flag off.

    1. "when bail_flow_trigger_on_unsupported_resource is disabled", which asserted the run still started for an unsupported resource.
    2. "with a template that declines the resource type", which turned the flag off so the run reached the goal template, and asserted the template forwarded a nil prompt without raising.

    With the flag gone, the service guard always stops the run before the template is reached, so the second scenario can no longer happen through the service. Coverage for the template-side and model-side guards (FoundationalFlow#supports_resource? and #resolve_additional_context_for returning [] for an unsupported resource) already exists in ee/spec/models/ai/catalog/foundational_flow_spec.rb, and the template's nil result for an issue is covered in ee/spec/models/ai/catalog/goal_templates/recommend_reviewers_spec.rb.

No frontend, docs, or API changes.

Screenshots or screen recordings

Not applicable. This change has no UI impact.

How to set up and validate locally

  1. Run bundle exec rspec ee/spec/services/ai/flow_triggers/run_service_spec.rb. Result: 167 examples, 0 failures.
  2. RuboCop is clean on the three changed Ruby files.
  3. No manual/UI validation is needed since this only removes a flag that has already been at 100 percent on GitLab.com for over a week.

MR acceptance checklist

Evaluated against https://docs.gitlab.com/development/code_review/#acceptance-checklist. This is a flag-removal cleanup with no behavior change from current production state, backed by the existing spec suite plus the RuboCop check above.

References

Merge request reports