perf(api): revert get_actions filters to scoring context (undo filter-context query-cache cost) by igorls · Pull Request #179 · eosrio/hyperion-history-api

igorls · 2026-06-04T12:23:39Z

Why

Reverts the "Tier-1" filter-context change from #176. During the WAX cold-tier incident, node-6 hot_threads showed IndicesQueryCache$CachingWeightWrapper.bulkScorer → LRUQueryCache…bulkScorer → TermQuery…seekExact dominating CPU. That's the query cache building bitsets for the filter-context term clauses: for a low-selectivity account (eosio.token) over large/old cold-tier segments, constructing the cached bitset (full per-segment enumeration) costs far more than the BM25 scoring it was meant to save, and it defeats index-sort early termination. Scoring (must) clauses are never query-cached, so moving back avoids that path.

What

applyAccountFilters, applyGenericFilters (terms + generic range), applyCodeActionFilters → back to must / root should+minimum_should_match (scoring context).
must_not and the @transfer.memo match were already scoring-context (unchanged).
applyTimeFilter ranges stay in filter context (range/can_match shard pruning — not the culprit).
Tests updated to pin scoring-context placement.

Scope / honesty

This removes the per-query amplification only. The underlying cold-tier load — a client walking old history via REST get_actions since ~May 25 — predates this change and is not fixed by it. Root fix still needs the offending query pattern/client identified (busy-window slowlog + access log) and bounded (rate-limit, or a guard keeping deep/old account queries off cold). hot-first (#176) already keeps the common eosio.token top-100 polls on the hot tier.

Testing

tsc --noEmit clean; bun test tests/unit → 121 pass.

…-context query-cache cost) The filter-context move (#176 'Tier-1') routed get_actions term clauses through ES's query cache. node-6 hot_threads during the WAX cold-tier incident showed IndicesQueryCache/LRUQueryCache bulkScorer dominating CPU: for a low-selectivity account like eosio.token over large/old cold-tier segments, *building* the cached bitset (full per-segment enumeration) costs far more than the BM25 it saved and defeats index-sort early termination. Move account / generic-term / code:name clauses back to must / root-should (scoring) context. must_not and the @transfer.memo match were already in scoring context; applyTimeFilter ranges stay in filter context (range pruning, not the culprit). Tests updated to pin scoring-context placement. Note: this removes the per-query amplification only — the underlying cold-tier load (a client walking old history via REST get_actions since ~May 25) predates this change and needs the client/query pattern identified + bounded separately.

gemini-code-assist

Code Review

This pull request refactors Elasticsearch queries in get_actions by moving several clauses from filter context (bool.filter) to scoring context (bool.must or root-level should) to optimize performance and prevent high caching overhead on low-selectivity queries. Unit tests have been updated to reflect these changes. The review feedback recommends retaining explicit minimum_should_match: 1 parameters in the nested bool queries as a defensive programming measure, along with updating the corresponding unit tests to assert this behavior.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

gemini-code-assist · 2026-06-04T12:24:50Z

    if (must.length > 1) {
-        (queryStruct.bool.filter ??= []).push({
+        queryStruct.bool.must.push({
            bool: {
                should: must.map(elem => {
                    const _q = {};
                    _q[field] = elem;
                    return {term: _q}
-                }),
-                minimum_should_match: 1
+                })
            }
        });


Explicitly specifying minimum_should_match: 1 for nested bool queries containing only should clauses is a defensive programming best practice. While Elasticsearch defaults minimum_should_match to 1 when there are no other clauses (like must or filter) in the same bool block, relying on this default is risky. If another developer later adds a must or filter clause to this nested bool query, the default would silently change to 0, making the should clauses optional and introducing subtle bugs.

Suggested change

if (must.length > 1) {

(queryStruct.bool.filter ??= []).push({

queryStruct.bool.must.push({

bool: {

should: must.map(elem => {

const _q = {};

_q[field] = elem;

return {term: _q}

}),

minimum_should_match: 1

})

}

});

if (must.length > 1) {

queryStruct.bool.must.push({

bool: {

should: must.map(elem => {

const _q = {};

_q[field] = elem;

return {term: _q}

}),

minimum_should_match: 1

}

});

gemini-code-assist · 2026-06-04T12:24:50Z

+        // *building* the cached bitset (full per-segment bulkScorer enumeration) costs far more than
+        // the BM25 it would save and defeats index-sort early termination. Observed dominating
+        // node-6 hot_threads (IndicesQueryCache.bulkScorer). See memory: filter-context-query-cache-tradeoff.
+        queryStruct.bool.must.push({"bool": {should: makeShouldArray(query)}});


Explicitly specifying minimum_should_match: 1 for the nested bool query ensures the query remains robust and behaves as expected even if other clauses are added to this nested block in the future.

queryStruct.bool.must.push({ bool: { should: makeShouldArray(query), minimum_should_match: 1 } });

gemini-code-assist · 2026-06-04T12:24:50Z

+        expect(qs.bool.filter).toBeUndefined();
+        expect(qs.bool.must).toHaveLength(1);
+        const clause = qs.bool.must[0];


Add the assertion for minimum_should_match back to ensure that the explicit behavior is pinned by the unit tests.

Suggested change

expect(qs.bool.filter).toBeUndefined();

expect(qs.bool.must).toHaveLength(1);

const clause = qs.bool.must[0];

expect(qs.bool.filter).toBeUndefined();

expect(qs.bool.must).toHaveLength(1);

const clause = qs.bool.must[0];

expect(clause.bool.minimum_should_match).toBe(1);

gemini-code-assist · 2026-06-04T12:24:50Z

+        expect(qs.bool.filter).toBeUndefined();
+        expect(qs.bool.must).toHaveLength(1);
+        expect(qs.bool.must[0].bool.should).toEqual([


Add the assertion for minimum_should_match back to ensure that the explicit behavior is pinned by the unit tests.

Suggested change

expect(qs.bool.filter).toBeUndefined();

expect(qs.bool.must).toHaveLength(1);

expect(qs.bool.must[0].bool.should).toEqual([

expect(qs.bool.filter).toBeUndefined();

expect(qs.bool.must).toHaveLength(1);

expect(qs.bool.must[0].bool.minimum_should_match).toBe(1);

expect(qs.bool.must[0].bool.should).toEqual([

Copilot

Pull request overview

This PR reverts the get_actions query-building change from PR #176 that moved term-based clauses into Elasticsearch filter context, restoring them to scoring context to avoid expensive query-cache bitset construction on low-selectivity account polls over large cold-tier segments.

Changes:

Move account, generic term/range filters, and code:name filters back to bool.must / root should + minimum_should_match (scoring context).
Keep time-range bounds in bool.filter for shard pruning (can_match) behavior.
Update unit tests to assert the restored scoring-context placement.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
`src/api/routes/v2-history/get_actions/functions.ts`	Reverts key query clauses from `bool.filter` back to `bool.must` / root `should` to avoid query-cache bitset build costs.
`tests/unit/filter-context.test.ts`	Updates assertions/comments to pin the intended scoring-context placement.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

+        // Scoring (must) context, NOT filter. Filter context routes this clause through ES's query
+        // cache; for a low-selectivity account like eosio.token over large/old (cold-tier) segments,
+        // *building* the cached bitset (full per-segment bulkScorer enumeration) costs far more than
+        // the BM25 it would save and defeats index-sort early termination. Observed dominating
+        // node-6 hot_threads (IndicesQueryCache.bulkScorer). See memory: filter-context-query-cache-tradeoff.


+// Filter context routes clauses through ES's query cache; for a low-selectivity account like
+// eosio.token over large/old (cold-tier) segments, building the cached bitset costs far more than
+// the BM25 it saves and defeats index-sort early termination (observed dominating node-6
+// hot_threads). These tests pin the scoring-context placement so it can't regress back to filter.
+// See memory: filter-context-query-cache-tradeoff.


Copilot AI review requested due to automatic review settings June 4, 2026 12:23

Copilot started reviewing on behalf of igorls June 4, 2026 12:23 View session

igorls merged commit 822d6fe into dev Jun 4, 2026
3 checks passed

gemini-code-assist Bot reviewed Jun 4, 2026

View reviewed changes

igorls deleted the revert/get-actions-filter-context branch June 4, 2026 12:25

Copilot AI reviewed Jun 4, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

perf(api): revert get_actions filters to scoring context (undo filter-context query-cache cost) - #179

perf(api): revert get_actions filters to scoring context (undo filter-context query-cache cost)#179
igorls merged 1 commit into
devfrom
revert/get-actions-filter-context

igorls commented Jun 4, 2026

Uh oh!

Uh oh!

gemini-code-assist Bot left a comment

Uh oh!

gemini-code-assist Bot Jun 4, 2026

Uh oh!

gemini-code-assist Bot Jun 4, 2026

Uh oh!

gemini-code-assist Bot Jun 4, 2026

Uh oh!

gemini-code-assist Bot Jun 4, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

igorls commented Jun 4, 2026

Why

What

Scope / honesty

Testing

Uh oh!

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist Bot Jun 4, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jun 4, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jun 4, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Jun 4, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants