[sarkaramrit1993]

SOLR-11994

Description

First step of SOLR-18571 (Query Insights). Adds a node-level hook that's notified when each top-level search finishes, so a module can track the slowest queries without parsing logs. Nothing changes unless a listener is registered.

Solution

• SearchRequestListener, registered through CoreContainer.addSearchRequestListener, following SolrCore.addConfListener.
• SearchHandler.handleRequest calls it on the coordinator after the search, with the request, ResponseBuilder, elapsed and CPU time, hits and any failure. Shard sub-requests, /get and /export aren't reported.
• Why SearchHandler: SolrCore.execute runs for every handler, so it would have to filter out updates and admin calls. A last SearchComponent misses failed requests and needs solrconfig changes. The slow-query log only gives a text line above a threshold.
• Listener exceptions are logged and don't affect the response.

Tests

SearchRequestListenerTest on a 2-shard cluster covers:

• one event per request, on the coordinator
• the request fields
• a failed search (400)
• a throwing listener
• /get and /export skipped
• shards.tolerant
• v2 /select
• CPU time

[nick-boss-tech]

🤖 AI text below 🤖 (reviewed by Nick Shanin)

@sarkaramrit1993, two cases turned up while reviewing this, so I prepared fixes on top of your current head (2c9243b111b3):

• With CPU logging enabled, a distributed query that fails during preparation can count coordinator CPU twice. The fix adds local CPU only when a shard CPU aggregate was actually published.
• [subquery] child searches have no isShard flag, so they produce extra top-level notifications, including on shard nodes. The fix excludes nested requests using the request stack and preserves notifications for top-level embedded searches.

Diff with fixes and regression tests. There are two follow-up commits: the fixes (b3a11484f13f) and a one-line formatting correction (23c68215cf0c).

Linux verification at 23c68215cf0c, with seed 5232C0DE:

• SearchRequestInfoTest and SearchRequestListenerTest: 17 tests passed, zero failures or skips; testCpuTime executed.
• TestSolrRequestInfo and TestSubQueryTransformerDistrib: 4 tests passed, zero failures or skips.
• ./gradlew tidy left a clean tree. ./gradlew check -x test passed with NODE_ENV unset. Its initial attempt failed in Antora because the host's NODE_ENV=production caused npm to omit devDependencies.

On the original PR code with the new tests, all three regressions fail as intended: the CPU snapshot reports 14 instead of 7, and distributed/local subquery requests produce 4 and 2 events instead of 1. Linux verification details.

To bring both follow-up commits into your PR branch:

git switch SOLR-11994-search-request-listener
git fetch https://github.com/nick-boss-tech/solr.git solr-11994-submit
git merge --ff-only 23c68215cf0c858b7dd1ceda6b945d2d9daaa174

You're welcome to take these commits or adapt the changes.

[sarkaramrit1993]

Closing in favor of #5238, which has the same change rebased on main as a single commit.

Thanks @nick-boss-tech, both findings were real.

• CPU double count: our own review caught the same case, so I kept the fix I'd already made. CPU time now comes only from the request log (shard total plus local CPU), and the response header isn't read.
• [subquery]: I took your SolrRequestInfo.isNestedRequest() check and your three tests as they were, plus a javadoc note. You're credited as co-author on the commit and listed in the changelog.