Take Duo Workflow Service URL and token from one feature setting

What does this MR do and why?

Duo Workflow Service clients now take the service URL, the TLS flag and the signing token from one feature setting.

WorkflowContextGenerationService#generate_workflow_token takes the URL and TLS flag from the flow's own setting (for Code Review, Agentic Code Review) but builds DuoWorkflowService::Client without it, so CloudConnector::Tokens.get falls back to the duo_agent_platform row, Agents & flows. When the two settings disagree, one service receives a token meant for the other:

  • When the flow is on a self-hosted model and Agents & flows is not, the self-hosted service receives the synced Cloud Connector token. An offline cloud license has none, so Code Review posts DCR4005.
  • On an online license, when the flow has no self-hosted setting of its own and Agents & flows is self-hosted, the GitLab-hosted service receives an instance-signed token.

Where the first case holds on an online license, the flow now also sends the instance's tool rules, which the self-hosted service applies. The issue has the trace.

Two API endpoints choose the self-hosted URL whenever one is configured, with the TLS flag from gitlab.yml.

  • POST /api/v4/ai/duo_workflows/direct_access does so even when the GitLab-hosted service minted the token whose capabilities and expiry it returns.
  • GET /api/v4/ai/duo_workflows/list_tools does so with a token signed from Agents & flows.

Both now take the URL and TLS flag from the setting behind the token, so the list_tools token is unchanged.

FlowsMetadataService and Catalog::Items::ValidateConfigService now also hand the client the Agents & flows setting they already use for the URL, as DuoAgentPlatformProbe does. Their tokens do not change.

Before and after

sequenceDiagram
  participant W as WorkflowContextGenerationService
  participant S as FeatureSettingSelectionService
  participant U as DuoWorkflow::Client.url_for
  participant C as DuoWorkflowService::Client
  participant T as CloudConnector::Tokens.get
  participant D as Self-hosted Duo Workflow Service
  W->>S: flow feature review_merge_request_dap
  S-->>W: Agentic Code Review setting, self-hosted
  W->>U: feature_setting is the flow setting
  U-->>W: duo_agent_platform_service_url
  W->>C: new with the URL
  Note over W,C: Before: feature_setting not passed<br/>After: feature_setting is the flow setting
  C->>T: unit primitive duo_agent_platform
  Note over T: Before: nil, reads the Agents and flows row<br/>After: signs from the flow setting
  T-->>C: bearer token
  Note over C,T: Before: synced token, empty when offline<br/>After: instance-signed token
  C->>D: GenerateToken
  D-->>C: Before, offline: UNAUTHENTICATED<br/>After: workflow token

The new spec rows assert the URL, bearer token and TLS flag together, through the real client and CloudConnector::Tokens. Two merge commits from master resolve conflicts in direct_access and in the context generation service spec, and the branch lands squashed. On the latest merge, with master at a16cd7fff652, the four changed spec files pass in defined and reverse order. Without the service and API changes, 23 examples fail. RuboCop is clean on the changed files.

An AI coding assistant wrote this change and this description, and ran each check above in a GitLab source checkout on two test VMs.

References

Screenshots or screen recordings

Not applicable: no UI change.

How to set up and validate locally

On a self-managed instance with an offline cloud license and a self-hosted Duo Workflow Service with authentication enabled:

  1. Assign a self-hosted model to Agentic Code Review and leave Agents & flows without one.
  2. In a merge request, comment /assign_reviewer @GitLabDuo.
  3. Without this change, GitLabDuo replies with DCR4005. With it, the review should start.

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 Andrew Dunn

Merge request reports

Loading
Loading