<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/engineering/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=632418) </details> <!--IssueSummary end--> ### Summary Workhorse sends two `x-gitlab-client-name` values to the Duo Workflow Service (DWS). Rails' resolved value (for example `chrome`) is sent first. Labkit's gRPC interceptor then adds `gitlab-duo-workflow`. DWS keeps only the last value, so the browser family never reaches DWS events. This is not a regression and does not block https://gitlab.com/gitlab-org/gitlab/-/merge_requests/257626. Before that MR, DWS already received `gitlab-duo-workflow`. ### Current behavior - Rails adds the resolved client identity (`x-gitlab-client-type`, `x-gitlab-client-name`) to the Duo Workflow connection config headers. Workhorse receives these in `cfg.Service.Headers`. - Workhorse forwards these headers on HTTP action requests to Rails. This works correctly. - Workhorse also sends `cfg.Service.Headers` as gRPC metadata when it opens the DWS stream. - The gRPC client also installs Labkit's `StreamClientCorrelationInterceptor`. Its client name comes from the original request's `X-Gitlab-Client-Name` header, or defaults to `gitlab-duo-workflow`. - Labkit appends this value to the outgoing metadata. It does not replace the existing one. - For a normal browser session, DWS receives: - `x-gitlab-client-name: chrome` - `x-gitlab-client-name: gitlab-duo-workflow` - DWS converts the metadata with `dict(...)`, so the last value wins. Running the real `InternalEventsInterceptor` with this metadata gives `client_type='browser', client_name='gitlab-duo-workflow'`. ### Expected behavior DWS receives exactly one `x-gitlab-client-name` value, and it is the value Rails resolved. For a Chrome session, DWS events show `client_type='browser', client_name='chrome'`. ### Impact - Rails action events attribute to `chrome`. - DWS internal events attribute to `gitlab-duo-workflow`. - Attribution is inconsistent between the two, and the browser family never appears in DWS events. ### Proposed fix Rails owns identity resolution (allowlist, aliases, User-Agent fallback). Workhorse should pass Rails' value through. It should not decide identity again, and a second injection should not override it. In Workhorse, pick one client name and send it once: 1. If the config has a non-empty `x-gitlab-client-name`, use it. For example, pass it as the Labkit interceptor's client name, or avoid the double injection. 1. Otherwise, use the original request's `X-Gitlab-Client-Name` header. 1. Otherwise, use `gitlab-duo-workflow`. Do not change DWS to read the first value. That would only hide the ambiguity. Add a test asserting that DWS receives exactly one client-name value when the config supplies one. The existing `client_test.go` tests use empty config headers, so they do not cover this case. <details> <summary>Code locations</summary> - Workhorse reads the request header and creates the client: https://gitlab.com/gitlab-org/gitlab/-/blob/b2078c09d3674e8a2657db65adefa859dc2bc01e/workhorse/internal/ai_assist/duoworkflow/stream_manager.go#L70-74 - Default name and interceptor install: https://gitlab.com/gitlab-org/gitlab/-/blob/b2078c09d3674e8a2657db65adefa859dc2bc01e/workhorse/internal/ai_assist/duoworkflow/client.go#L47-66 - Config headers seeded as outgoing metadata: https://gitlab.com/gitlab-org/gitlab/-/blob/b2078c09d3674e8a2657db65adefa859dc2bc01e/workhorse/internal/ai_assist/duoworkflow/client.go#L108 - Labkit append (`gitlab.com/gitlab-org/labkit` v1.65.0, `correlation/grpc/client_interceptors.go`): https://gitlab.com/gitlab-org/labkit/-/blob/v1.65.0/correlation/grpc/client_interceptors.go#L17-18 - Rails adds the fallback name: https://gitlab.com/gitlab-org/gitlab/-/blob/b2078c09d3674e8a2657db65adefa859dc2bc01e/ee/app/services/ai/duo_workflows/connection_config_service.rb#L97-101 - DWS dict conversion: https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/blob/2ea8704c73229429c5e84e2fe0ed792f0bb494a5/duo_workflow_service/interceptors/internal_events_interceptor.py#L61 - DWS `client_name` read: https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/blob/2ea8704c73229429c5e84e2fe0ed792f0bb494a5/duo_workflow_service/interceptors/internal_events_interceptor.py#L155 </details> <details> <summary>Reproduction</summary> 1. Open an agentic chat from a Chrome browser. The websocket upgrade has no `X-Gitlab-Client-Name` header. 1. Inspect the gRPC metadata received by DWS, or the DWS internal event context. 1. `client_name` is `gitlab-duo-workflow`. 1. The Rails-side `meta.client_name` for the action requests is `chrome`. </details>