## Summary Add feature flag and routing logic on GitLab.com to support the new `leads/gitlab_com/addons` endpoint on CustomersDot. ## Problem GitLab.com currently sends addon trial requests to CustomersDot where both lead creation and trial application happen in one call. We need to add a feature flag to split this into two calls: lead creation first, then trial application. ## Prerequisites - [x] CustomersDot issue completed: New `Leads::GitlabCom::AddonsController` deployed to production - [ ] New endpoint verified working in CustomersDot staging ## Implementation Details ### Feature Flag **Name:** `new_addon_lead_endpoint` **Type:** `gitlab_com_derisk` (percentage-based rollout) **Default:** `false` - [x] Create a feature flag rollout issue following https://docs.gitlab.com/development/feature_flags/#create-a-new-feature-flag - [x] Add the issue to the current epic ### Code Changes **Locate addon trial creation code:** - Find where GitLab.com calls CustomersDot for addon trials (Duo Pro, Duo Enterprise) - Likely in a service, helper, or controller **Add conditional routing:** ```ruby def create_addon_trial_with_lead if Feature.enabled?(:new_addon_lead_endpoint) # New flow: Create lead first, then apply trial create_addon_lead # Call new leads endpoint apply_addon_trial # Call existing trials endpoint else # Legacy flow: Single call handles both create_addon_trial_legacy end end ``` ## Rollout Plan This issue creates the feature flag infrastructure. Actual rollout will be handled in a separate rollout issue following GitLab's feature flag rollout process. ## Related - Parent Epic: https://gitlab.com/groups/gitlab-org/-/epics/20106