Add feature flag support for iterable lead endpoint migration

Buck O'Learyrequested to merge
582577-add-feature-flag-for-new-iterables-endpoint into master

What does this MR do and why?

Adds the new_iterable_lead_endpoint feature flag and uses it to select which CustomersDot endpoint Gitlab::SubscriptionPortal::Clients::REST#generate_iterable posts to:

Flag Endpoint
off (default) POST trials/create_iterable — current behaviour
on POST leads/gitlab_com/iterables

Selection lives in one private method, iterable_endpoint. Nothing else changes: no call site, worker, or payload is touched, and every caller of generate_iterable moves together when the flag flips.

Why the flag is instance-scoped

Feature.enabled?(:new_iterable_lead_endpoint, :instance).

Which endpoint to call is a property of the CustomersDot deployment, not of a user. A percentage-of-actors rollout would split iterable traffic across two endpoints without making anything safer, and would require threading the user through Onboarding::CreateIterableTriggerWorker and its call sites.

Earlier revisions of this MR did that — an added worker argument, an actor passed through the migrating services, and a create_account carve-out in the client to hold non-parity payloads on the legacy endpoint. None of it remains. CreateIterableTriggerWorker#perform keeps its current signature, so the Sidekiq argument-compatibility guidance no longer applies here.

Deployment dependency

Endpoint parity is handled on the CustomersDot side by https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/17091, which makes Leads::GitlabCom::IterablesController delegate to Leads::GitlabCom::CreateIterableService. That gives the new endpoint the same handling of create_account (account creation) and glm_source / glm_content (attribution) as the legacy one, which is why this MR needs no per-flow exclusions.

!17091 (merged) must be deployed before this flag is enabled anywhere. Both endpoints answer { success: true } regardless of what they did with the payload, so enabling early would drop account creation and glm attribution with no error and no failing test.

Feature flag

  • Type gitlab_com_derisk, default_enabled: false, milestone 19.5
  • Rollout issue: #608866
  • Feature issue: #582577 (closed)

How to set up and validate locally

  1. Simulate a SaaS instance and restart GDK.
  2. bin/rspec ee/spec/lib/gitlab/subscription_portal/clients/rest_spec.rb
  3. With the flag off, register through any iterable flow and confirm the request goes to trials/create_iterable.
  4. Feature.enable(:new_iterable_lead_endpoint), repeat, and confirm it goes to leads/gitlab_com/iterables.

Related

MR acceptance checklist

  • Tests added for this feature/bug
  • Feature flag documented with a rollout issue
Edited by Buck O'Leary

Merge request reports