Skip to content

Remote flows for DAP do not work with self-hosted models and model switching, and should be fixed.

Currently, only websockets connection support model switching and using self-hosted models.

Websockets connection is only used for:

Remote flows do not currently work with self-hosted models and model switching. Remote flows are flows that are initiated from within the GitLab UI and runs within a CI job, for eg: "Generate MR with Duo"

Reason:

A remote flow runs within a CI job, using the Duo Workflow Executor.

The Duo Workflow Executor is a Golang program that talks to the Duo worklflow Service and gets the required flow executed.

However, the auth process between Duo Workflow Executor and Duo Worklflow Service happens via the duo_workflows/direct_access endpoint.

And this endpoint has not been adapted for model switching or self-hosted models, like the ws endpoint has to work with websockets.

Which is the root cause why model switching or self-hosted models do not work today with remote flows.

Proposal

The ideal way to solve this is:

- Duo Workflow executor makes a call to /direct_access endpoint with namespace_id information along with the call (for .com). For self-managed and self-hosted instances, namespace_id does not matter to fetch model information, but it can be passed in all kinds of instances nonetheless. - within /direct_access, we then fetch the model information using DuoAgentPlatformModelMetadataService - We pass this value along with existing headers. - Duo Workflow Executor grabs this specific header. - Duo Workflow Executor passes this header information along to Duo Workflow Service. - Duo Workflow Service is already equipped to grab this information from the headers, and set the specific model in the global context, which will be used to power the request.

Igor suggested that the above idea maybe a security risk, because we will be exposing model information within direct_access response.

An alternative is to:

  • Update the list of variables here so that model metadata information is also a variable
  • Inside the executor, we will grab this variable and make it a header.
  • Executor will pass this header along to the Duo workflow service.

This is also a better approach than the previous one because project is already available here as a method, so we can easily obtain namespace out of it (for the .com model switching use case)

Blockers/questions:

We have a Golang executor and a Node executor. We have plans to deprecate the Golang executor. So the question is:

Do we wait until Node Executor is extracted from LSP? Using the node executor has the advantage that all of the above changes aren't necessary, as the node executor works via websockets already, so ws endpoint will be used.

Edited by Manoj M J