Marc Byrd created SOLR-18487:
--------------------------------
Summary: V2 CollectionApiCommands NPE (AdminCmdContext) is a
new-to-10.1 regression, not the pre-existing SOLR-18324 — introduced by
SOLR-18072, exposed by SOLR-15752
Key: SOLR-18487
URL: https://issues.apache.org/jira/browse/SOLR-18487
Project: Solr
Issue Type: Bug
Affects Versions: 10.1
Reporter: Marc Byrd
This is a distinct, new-to-10.1 regression, not a duplicate of SOLR-18324
(which its own reporter flags as likely pre-existing/long-standing). Filing
separately per discussion with Hoss Hostetter, so the regression gets accurate
visibility for the 10.1.0 RC vote.
#
## What's new in 10.1 (confirmed via git history against the
releases/solr/10.0.0 tag)
Two independent changes landed in 10.1, and together they turn a latent edge
case into a routine, everyday failure:
1. *{*}SOLR-18072{*}* ("Refactor CollectionApiCommands to add expandable
context") introduced `AdminCmdContext` and the new
`AdminAPIBase.submitRemoteMessageAndHandleAsync`/`submitRemoteMessageAndHandleResponse`
split. Neither `AdminCmdContext.java` nor the
`submitRemoteMessageAndHandleAsync` method exist anywhere in the
`releases/solr/10.0.0` tree. 10.0's `AdminAPIBase` had only a single, simpler
`submitRemoteMessageAndHandleResponse` method using the instance's own
`solrQueryRequest` field – never a separately-threaded `req` parameter that
could end up null.
2. *{*}SOLR-15752{*}* ("Migrate admin UI to v2 apis") made the classic Admin UI
use the V2 REST API exclusively for actions like Add Replica, Reload, etc. –
also not present in 10.0 (commit f96c4b3cfd3 is not an ancestor of the 10.0.0
tag). In 10.0, clicking "Add Replica" in the Admin UI went through the classic
V1 handler and never touched this code at all.
*{*}The combination matters more than either change alone.{*}* Even granting
SOLR-18324's own uncertainty about how long its general bug class ("a V2
request fails before V2HttpCall attaches SolrQueryRequest to the Jersey
context") has existed somewhere in the V2 stack – nothing in ordinary 10.0
usage ever exercised that class of bug via the Admin UI, because V2 wasn't the
default path. 10.1 is the first release where a normal user clicking a button
in the bundled Admin UI reaches this code unconditionally.
Reproduction (confirmed reachable with zero reverse-proxy involvement)
Reproduced directly against a real Solr 10.1.0 RC1 build via `kubectl
port-forward` straight to the Solr service, bypassing every layer of our own
product's (Fusion) proxying entirely – this rules out any proxy/reverse-proxy
explanation and confirms the bug is 100% within Solr's own V2 REST
implementation:
{code:java}
POST /api/collections/{collection}/shards/{shard}/replicas (ADDREPLICA via
Admin UI)
java.lang.NullPointerException: Cannot invoke
"org.apache.solr.request.SolrQueryRequest.getContext()" because "req" is null
at
org.apache.solr.cloud.api.collections.AdminCmdContext.<init>(AdminCmdContext.java:46)
at
org.apache.solr.handler.admin.api.AdminAPIBase.submitRemoteMessageAndHandleAsync(AdminAPIBase.java:150)
at
org.apache.solr.handler.admin.api.AdminAPIBase.submitRemoteMessageAndHandleResponse(AdminAPIBase.java:168)
at
org.apache.solr.handler.admin.api.CreateReplica.createReplica(CreateReplica.java:92)
{code}
Reproduced this twice independently – once as a side effect of an unrelated
failure (masking the real error), and once as a clean repro with no other error
to mask, confirming the NPE fires unconditionally for this code path rather
than only when something else already failed.
#
## Relationship to SOLR-18324
SOLR-18324's fix (PR #4676) touches RequestHandlerBase,
CatchAllExceptionMapper, PostRequestDecorationFilter, PostRequestLoggingFilter,
and RequestMetricHandling – it does NOT touch AdminCmdContext.java or
AdminAPIBase.java. So even with that fix applied, this specific trigger will
still throw (the secondary "exception mapper itself crashes" symptom would
likely be fixed, surfacing a cleaner error, but the underlying NPE in
AdminCmdContext remains).
Impact
AdminAPIBase.submitRemoteMessageAndHandleAsync/Response is shared by many V2
collection-admin operations (confirmed via ReloadCollectionAPI and
CreateReplica so far), so this is likely reachable from other admin operations
using the same base method. Any V2 admin operation triggered through the
now-V2-exclusive Admin UI can return a completely opaque 500 with zero
diagnostic information, in situations where the V1 equivalent returns a proper,
actionable error body.
Suggested fix
Null-check `req` in AdminCmdContext's constructor (or fix why req is null in
this async path) consistent with the null-guards SOLR-18324 already added
elsewhere in the V2 request-handling stack.
*Links:* relates to SOLR-18324, caused by SOLR-18072, exposed in practice by
SOLR-15752.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
