Refactor ExecuteWorkflowService to accept pre-resolved flow params

Thomas Schmidtrequested to merge
ts/execute-workflow-caller-resolves into master

What does this MR do and why?

Refactors ExecuteWorkflowService to accept pre-resolved flow routing params (flow_config_id, flow_config_schema_version, flow_version) from callers instead of calling FoundationalFlowStartParamsResolver internally.

Key changes

  • ExecuteWorkflowService — accepts flow_config_id, flow_config_schema_version, flow_version as params. No longer calls FoundationalFlowStartParamsResolver internally.
  • Flows::ExecuteService — calls the resolver itself and passes the resolved routing params to ExecuteWorkflowService. Non-foundational flows are unaffected.
  • FoundationalFlowStartParamsResolver — no longer returns flow_definition. It only returns routing components (flow_config_id, flow_config_schema_version, flow_version), cleanly separating the stable flow identity from engine routing.
  • StartWorkflowService — uses @workflow.workflow_definition (stable identity) for RunWorkloadService rate limiting, and derives the legacy DUO_WORKFLOW_DEFINITION env var from the routing components for backward compatibility with older CLI versions.

This aligns with the four-property model discussed in !235204 (merged) and the direction outlined in #599841.

References

How to set up and validate locally

  1. Ensure developer-related feature flags are off (default state): 
    Feature.disable(:duo_developer_next_unstable)
  2. Trigger Duo Developer on a work item by mentioning @duo-developer-gitlab-duo
  3. Confirm the flow starts successfully
  4. Enable the feature flag to override flow routing: 
    Feature.enable(:duo_developer_next_unstable)
  5. Trigger Duo Developer again and confirm it still starts successfully

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.

Merge request reports