Move feature library AI search into a separate endpoint

What does this MR do and why?

Feature Discovery Search's Tier 3 (Gemini) previously ran inline in the synchronous feature_library#search request. This MR splits Tier 3 (ai search) into a dedicated, user-triggered ai_search endpoint so the deterministic search stays fast and the AI tier is only invoked as an explicit follow-up action (this is the intended UX).

This MR:

  • Adds GET /-/onboarding/feature_library/ai_search, gated on the feature_discovery_gemini_search flag (404 when disabled).
  • Splits FeatureMatchService#execute (Tier 1/2 only) from a new public #ai_execute (Tier 3). Adds #ai_search_enabled? (CE stub / EE override) so FOSS code can check the EE-only flag without referencing it directly.
  • Moves the ai_search_available signal out of search and into the ai_search response, letting the client distinguish "no AI results" (true, empty ids) from "AI search unavailable" (false).
  • Adds a dedicated feature_library_ai_search rate limit (10/min/user) sized as an abuse ceiling for the expensive LLM path.
  • Adds a frontend path helper for the new endpoint.

References

Screenshots or screen recordings

Backend-only; no UI changes. The frontend button that calls this endpoint is tracked separately.

How to set up and validate locally

  1. Enable feature_library_modal and feature_discovery_gemini_search, simulate SaaS, and use a group on an active trial.
  2. GET /-/onboarding/feature_library/ai_search?query=<query>&panel=group&resource_id=<group_id>
  3. Confirm: flag off → 404; unavailable (no trial/resource) → 200 { ids: [], ai_search_available: false }; available → 200 { ids: [...], ai_search_available: true }.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist.

Edited by Kiesha Herman

Merge request reports

Loading
Loading