## Why this epic exists The Elasticsearch-backed work item finder is **already built and already serving production traffic**. `ee/lib/ee/search/advanced_finders/work_items_finder.rb` is a complete replacement for the Postgres `WorkItems::WorkItemsFinder`, dispatched from `app/graphql/resolvers/work_items_resolver.rb` line 55, and it reuses the same index and query builder as global Advanced Search rather than standing up a parallel stack. GLQL has been served by it globally on GitLab.com since 2026-04-02 with no incidents. The work item list has not: `work_items_list_es_integration` has been disabled since 2025-11-25. So the remaining work is not "build an Elasticsearch finder". It is three separable problems, **only one of which is tracked today**. | Problem | Tracked? | Where | |---|---|---| | Filter and sort parity | Yes | [GLQL to ES WorkItems Filters Integration](https://gitlab.com/groups/gitlab-org/-/epics/17460) | | Tab and state counts still on Postgres | **No** | this epic | | Correctness divergence between the two backends | **No** | this epic | | Rollout unblocking and ownership | Stalled | this epic | This epic covers the second, third and fourth rows. It deliberately does **not** duplicate the filter parity work, which has a healthy child list under the epic linked above. ## The three problems ### 1. Counts never moved to Elasticsearch Both state count resolvers call the Postgres finder directly. Neither mentions the advanced finder: - `app/graphql/resolvers/namespaces/work_item_state_counts_resolver.rb` line 11 - `app/graphql/resolvers/work_item_state_counts_resolver.rb` line 10 They hand it to `Gitlab::IssuablesCountForState`, which wraps the query in a 4.5 second timeout and returns a placeholder on failure (`lib/gitlab/issuables_count_for_state.rb` lines 94 to 108). The comment immediately above that code, in the repository today, nominates the fix: > Determining counts when referring to issuable titles or descriptions can be very expensive, and involve the database reading gigabytes of data for a relatively minor piece of functionality. This may slow index pages by seconds in the best case, or lead to a statement timeout in the worst case. **In time, we may be able to use elasticsearch or postgresql tsv columns to perform the calculation more efficiently.** The consequence for the rollout: with the flag fully enabled, the issue list's rows get fast and its counts stay slow. We would ship a page that is half migrated. ### 2. Two correctness divergences are live on the GLQL path today These are not rollout risks. They are defects users can hit right now, because GLQL is enabled globally. - **Issues from banned users stay visible.** Postgres hides them with a live anti-join. Elasticsearch reads an index-time boolean snapshot, and no code path reindexes an author's work items when they are banned. - **Hierarchy control flags are silently ignored.** `include_descendants: false`, `exclude_projects`, `include_ancestors` and `exclude_group_work_items` are stripped before the supported-filter check, so a request asking to narrow the scope is served the whole subtree instead of falling back to Postgres. The second one matters disproportionately because it is the only place the finder's fail-safe design fails. Every other unsupported parameter routes the request back to Postgres. These four change the result set instead. ### 3. Nothing verifies the two backends agree A repository-wide search for a shadow mode, a result comparator, or any dual-read parity check returns nothing. For a migration whose failure mode is a quietly wrong issue list, we have no instrument that would detect it. ## Rollout state | | `glql_es_integration` | `work_items_list_es_integration` | |---|---|---| | Default | enabled | disabled | | Production | globally on since 2026-04-02 | off since 2025-11-25 | | Rollout issue | https://gitlab.com/gitlab-org/gitlab/-/issues/527280 | https://gitlab.com/gitlab-org/gitlab/-/issues/561475 | The list flag was enabled for a feature group on 2025-10-06 and reverted the same day after Plan stage smoke tests failed on staging-canary. That is still the newest technical comment on its rollout issue. There has been no engineering activity in 2026, the milestone is Backlog, and the original DRI has left GitLab. The flag currently carries three different team labels across the flag definition, the rollout issue, and the code's own directory. The smoke test failure predates roughly eleven months of refactoring, including the query builder's migration to declarative query components in 2026-05. Re-running it is one pipeline. ## Scope **In scope** - Elasticsearch-backed state counts for the work item list - The two live correctness defects above - A parity verification harness good enough to gate the rollout - Naming an owner and re-testing the flag **Out of scope** - Filter and sort parity, tracked at https://gitlab.com/groups/gitlab-org/-/epics/17460 - Indexing all work items rather than paid namespaces only, tracked at https://gitlab.com/gitlab-org/gitlab/-/issues/526224 - Reducing index lag, tracked at https://gitlab.com/gitlab-org/gitlab/-/issues/553407 and https://gitlab.com/gitlab-org/gitlab/-/issues/566187 ## Sequencing The two defects are independent and can start immediately. The harness should land before the flag is re-enabled, because it is the instrument that tells us whether re-enabling worked. Counts are the largest single user-visible win and the reason to do the rollout at all. ## Work items 1. [Advanced search: serve work item list state counts from Elasticsearch](https://gitlab.com/gitlab-org/gitlab/-/work_items/628641) 2. [Advanced search: work items of banned authors stay visible because nothing reindexes them on ban](https://gitlab.com/gitlab-org/gitlab/-/work_items/628642) 3. [Advanced search: hierarchy control flags are silently ignored instead of falling back to Postgres](https://gitlab.com/gitlab-org/gitlab/-/work_items/628643) 4. [Advanced search: build an Elasticsearch vs Postgres result parity harness for the work item list](https://gitlab.com/gitlab-org/gitlab/-/work_items/628644) 5. [Unblock the work_items_list_es_integration rollout: name a DRI and re-test the 2025 smoke failure](https://gitlab.com/gitlab-org/gitlab/-/work_items/628645) ## Related - [GLQL to ES WorkItems Filters Integration](https://gitlab.com/groups/gitlab-org/-/epics/17460) tracks filter parity. Its matrix is GLQL-shaped, so it omits list-only concerns such as manual ordering and priority sorts. If a maintainer prefers, the work here can be folded in there instead of standing alone. - [Work Items Performance Working Group](https://gitlab.com/groups/gitlab-org/-/epics/16919) carries the business case, including the measured six second baseline for the first hundred unfiltered work items in this group. - [Include archived argument broke GLQL](https://gitlab.com/gitlab-org/gitlab/-/issues/573896) is the precedent for how sharply this path fails: one unhandled parameter dropped every GLQL query back to Postgres. ## Provenance Every code reference in this epic and its children was read at commit `0c2053838c1efb839422477ccfbf7b8d76db2c10` on `master`. Line numbers drift, so enclosing method and constant names are given alongside them.