Fix NPE/RTimer assertion when a V2 request fails before a SolrQueryRequest is attached

[epugh]

Summary

Discovered while investigating an intermittent CollectionsApi.GetCollectionStatus failure under basic-auth-secured clusters (used while migrating bin/solr delete off ZooKeeper). The endpoint would fail intermittently with:

SEVERE: An exception has been thrown from an exception mapper class org.apache.solr.jersey.CatchAllExceptionMapper.
java.lang.NullPointerException: Cannot invoke "org.apache.solr.request.SolrQueryRequest.getCore()" because "req" is null
	at org.apache.solr.handler.RequestHandlerBase.processReceivedException(RequestHandlerBase.java:326)
	at org.apache.solr.jersey.CatchAllExceptionMapper.processAndRespondToException(CatchAllExceptionMapper.java:93)

...cascading into Jersey re-invoking the response filter chain via its "already mapped exception" fallback path, which in turn caused RequestMetricHandling.PostRequestMetricsFilter to call .stop() a second time on an already-stopped timer — tripping RTimer's assert state == STARTED || state == PAUSED (only visible with assertions enabled, e.g. under -ea test runs; silently harmless in production builds where the assert is compiled out).

Root cause: when a request fails before V2HttpCall attaches a SolrQueryRequest to the Jersey request context (the actual trigger appears to be a rare race in inter-node request handling — not fully root-caused, but independent of any specific endpoint), several Jersey filters/mappers in org.apache.solr.jersey unconditionally dereference that possibly-null SolrQueryRequest, causing a second, cascading exception while trying to handle the first one.

Changes

• RequestHandlerBase.processReceivedException: null-check req before calling req.getCore().
• CatchAllExceptionMapper.buildExceptionResponse: null-check solrQueryRequest before calling .getParams().
• PostRequestDecorationFilter / PostRequestLoggingFilter: null-check solrQueryRequest before dereferencing (mirrors the existing, correct null-check already present in MediaTypeOverridingFilter, which had a // TODO Is it valid for SQRequest to be null? comment confirming this was already a known possibility).
• RequestMetricHandling.PostRequestMetricsFilter: guards against being invoked more than once for the same request by clearing the TIMER property after stopping it, so a second (re-entrant) invocation is a no-op instead of crashing.

Test plan

• New unit tests: RequestHandlerBaseTest (null req cases), PostRequestLoggingFilterTest, PostRequestDecorationFilterTest (new), RequestMetricHandlingTest (new) — each verified to fail without the corresponding fix and pass with it (confirmed RequestMetricHandlingTest.testPostRequestMetricsFilterToleratesBeingInvokedTwice fails on git stash of just the RequestMetricHandling.java fix, passes once restored)
• Existing CatchAllExceptionMapperTest (SOLR-18066) still passes — no regression to hideStackTrace handling
• Reproduced the original intermittent failure with a throwaway integration test hitting GetCollectionStatus under a SecurityJson.SIMPLE-secured 2-node cluster (~40% failure rate over multiple runs); with these fixes applied, 15/15 consecutive runs passed
• ./gradlew :solr:core:spotlessJavaCheck clean
• ./gradlew :solr:core:compileJava :solr:core:compileTestJava clean

🤖 Generated with Claude Code

[epugh]

I am still trying to "prove" that this is an issue on main....

[der-eismann]

Hey @epugh, are you sure you referenced the right issue? Wondering because I'm the author of SOLR-18322 and I don't see how that's relevant for it 🙂

[epugh]

Hey @epugh, are you sure you referenced the right issue? Wondering because I'm the author of SOLR-18322 and I don't see how that's relevant for it 🙂

So, I just yelled at my damn Claude... who went rogue and opend up this PR while I was just chatting... Sigh. Thank you. So then I was going to just go and open a JIRA and get that number! THanks.

[epugh]

Hey @epugh, are you sure you referenced the right issue? Wondering because I'm the author of SOLR-18322 and I don't see how that's relevant for it 🙂

So, I just yelled at my damn Claude... who went rogue and opend up this PR while I was just chatting... Sigh. Thank you. So then I was going to just go and open a JIRA and get that number! THanks.

i actually was shocked that it just "did it", I know, I shouldn't have been.

[epugh]

This PR was accidentally closed when its branch got renamed outside of GitHub's branch-rename API (which would have carried the PR along automatically) — the branch was deleted instead, which auto-closes any PR pointing at it. Reopened with the same content, corrected to reference the actual JIRA ticket number, as #4676.