Send a single x-gitlab-client-name to DWS from Workhorse

Marcel van Remmerdenrequested to merge
duo/fix/632418-single-dws-client-name into master

What does this MR do and why?

Workhorse sent two x-gitlab-client-name values to the Duo Workflow Service (DWS):

  1. The value Rails resolved (for example chrome), from the config headers.
  2. The value Labkit's StreamClientCorrelationInterceptor adds. It comes from the request header, or defaults to gitlab-duo-workflow.

DWS keeps only the last value, so the browser family never showed up in DWS events.

With this change, NewClient removes x-gitlab-client-name from the headers it sends as gRPC metadata. It passes that value to the Labkit interceptor as the client name instead, so DWS gets exactly one value. Workhorse picks the value in this order:

  1. A non-empty x-gitlab-client-name from the config headers (the value Rails resolved). The header name is matched case-insensitively.
  2. The original request's X-Gitlab-Client-Name header.
  3. gitlab-duo-workflow.

The caller's config.Headers map is not changed. Workhorse still uses it for HTTP action requests to Rails.

References

Resolves #632418

How to set up and validate locally

cd workhorse
go test ./internal/ai_assist/duoworkflow -run TestClient -count=1

New tests check that DWS gets exactly one x-gitlab-client-name (chrome) when the config supplies one, for both lowercase and mixed-case header names. They also check that an empty config value falls back to the request's client name.

Note: I couldn't run these tests where I made the change because Go module downloads were blocked (proxy.golang.org returned 403). Only gofmt was run. CI must confirm the tests pass.

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