[
https://issues.apache.org/jira/browse/SOLR-18487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Byrd updated SOLR-18487:
-----------------------------
Description:
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.
was:
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.
> 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
> Priority: Major
>
> 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]
