Wire software_development_flow_registry feature flag

What does this MR do and why?

As part of the migration of AI flows to the flow registry, this MR wires up the software_development_flow_registry feature flag on the Rails side.

The software_development flow runs entirely in the IDE — the LSP connects directly to the AI Gateway (Duo Workflow Service) and sends a startRequest proto that specifies which flow to run. Rails is not involved in that decision directly, but it does forward enabled feature flags to the LSP via the x-gitlab-enabled-feature-flags response header on the /ws endpoint.

This MR adds software_development_flow_registry to that header (scoped to root_namespace), so the LSP can read it and decide whether to send flowConfigId: "software_development" + flowConfigSchemaVersion: "v1" + flowVersion: "1.0.0" in the startRequest (registry path), or fall back to workflowDefinition: "software_development" (legacy path).

When the flag is disabled (default), the header is absent and the LSP uses the legacy path — behaviour is unchanged.

When the flag is enabled for a namespace, the header is present and the LSP switches to the software_development/v1 flow registry definition in Duo Workflow Service.

References

Screenshots or screen recordings

No UI changes.

How to set up and validate locally

  1. Enable the feature flag for a namespace in the Rails console:
    Feature.enable(:software_development_flow_registry, Namespace.find_by_path('your-namespace'))
  2. Call the /ws endpoint (e.g. by opening a Duo Workflow session in the IDE).
  3. Verify the x-gitlab-enabled-feature-flags header in the response includes software_development_flow_registry.
  4. Disable the flag and confirm the header no longer includes it.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Tim Morriss

Merge request reports

Loading