Remove lock_workflows_for_web_only feature flag

Igor Drozdovrequested to merge
duo/refactor/591407-remove-lock-workflows-for-web-only-flag into master

What does this MR do and why?

Removes the lock_workflows_for_web_only feature flag.

The flag was a temporary gitlab_com_derisk switch that let GitLab.com skip concurrency locking for clients other than the browser. Locking now works correctly for every client type and the flag is disabled everywhere, which is the desired end state.

Because the flag is disabled, Feature.disabled?(:lock_workflows_for_web_only, current_user) already returned true, so the guarded expression evaluated to true for every request regardless of client_type:

LockConcurrentFlow: client_type == 'browser' || Feature.disabled?(:lock_workflows_for_web_only, current_user)

It collapses to LockConcurrentFlow: true, so this MR is a no-op for production behavior.

Changes:

  1. Deleted ee/config/feature_flags/gitlab_com_derisk/lock_workflows_for_web_only.yml.
  2. Collapsed the conditional in ee/lib/api/ai/duo_workflows/workflows.rb to the constant true.
  3. Dropped the flag_enabled dimension from the LockConcurrentFlow spec table. The remaining cases still cover all three client_type values (nil, browser, node-websocket), so client-type independence stays under test rather than being silently dropped.

Why LockConcurrentFlow stays in the payload

The key is deliberately kept rather than removed. Workhorse still reads it (LockConcurrentFlow bool in workhorse/internal/api/api.go, consumed in internal/ai_assist/duoworkflow/runner.go). Since a Go bool zero value is false, omitting the key would decode to false and silently disable locking. Removing the field on the Workhorse side is a separate follow-up that has to outlive clients running older Workhorse builds.

References

Screenshots or screen recordings

Not applicable, no user-visible UI change.

How to set up and validate locally

  1. Confirm no references to the flag remain:

    git grep lock_workflows_for_web_only

  2. Run the request spec:

    bundle exec rspec ee/spec/requests/api/ai/duo_workflows/workflows_spec.rb

  3. Call the direct access endpoint with any client_type and confirm LockConcurrentFlow is true:

    curl --header "Authorization: Bearer $TOKEN" \
  "http://gdk.test:3000/api/v4/ai/duo_workflows/direct_access?project_id=1&client_type=node-websocket"

Testing

Run locally on this branch:

  • bundle exec rspec ee/spec/requests/api/ai/duo_workflows/workflows_spec.rb — 433 examples, 0 failures, 14 pending. The pending examples are pre-existing skips in granular_token_permissions_shared_examples.rb, unrelated to this change.
  • bundle exec rubocop on both changed Ruby files — no offenses.

Not run: the Workhorse Go test suite. No Go files are touched by this MR, so the existing LockConcurrentFlow: true / false fixtures are unaffected, but that reasoning was not confirmed by an actual test run.

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