[go: up one dir, main page]

Skip to content

Ensure WorkItem label changes trigger Advanced Search updates

What does this MR do and why?

Fix GLQL query inconsistencies for WorkItem label filters by ensuring Elasticsearch stays synchronized when labels are added or removed from WorkItems (including Epic WorkItems).

GLQL queries with label filters were returning different results when using Elasticsearch compared to direct database queries. For example, a query for Plan Stage Roadmap epics returned only 1 result via ES but 10 results when bypassing ES with ?useES=false.

The root cause was that WorkItem was not included in the LABEL_INDEXED_MODELS constant in ee/app/models/ee/label_link.rb, which meant that label changes on WorkItems (particularly Epic WorkItems) were not triggering Elasticsearch updates.

Solution

  • Add WorkItem to indexed models: Include WorkItem in LABEL_INDEXED_MODELS to ensure label changes trigger Elasticsearch updates
  • Reindex existing documents: Bump WorkItem schema version to 25_43 and add migration to reindex existing WorkItem documents with proper label data
  • Comprehensive testing: Add test coverage for WorkItem label synchronization

References

Closes #577643

Screenshots or screen recordings

Not applicable - backend logic change only.

How to set up and validate locally

  1. Enable the glql_es_integration feature flag for your user via chatops
  2. Create a GLQL query with label filters in a wiki page or issue note:
    ```glql
    display: table
    title: Test WorkItem Labels
    fields: labels("group::*") as "Group", title, state
    query: group = "gitlab-org" AND type = Epic AND label = ~"your-label"
    ```
  3. View the results with Elasticsearch enabled
  4. Add ?useES=false parameter to the page URL and compare results
  5. Both should now return the same number of results
  6. Run the test suite to validate the fix:
    bin/rspec ee/spec/models/ee/label_link_spec.rb

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.

  • I have evaluated the MR acceptance checklist for this MR.
  • This change is backward compatible.
  • This change does not require feature flag changes.
  • This change includes proper test coverage.
Edited by Dmitry Gruzd

Merge request reports

Loading