[
https://issues.apache.org/jira/browse/SOLR-18487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18121321#comment-18121321
]
Marc Byrd commented on SOLR-18487:
----------------------------------
Correction re suggested fix:
A bare null-check in AdminCmdContext's constructor is incomplete.
initAdminRequest() (skipped entirely on the ADMIN_OR_REMOTEPROXY path) is also
the only place that copies the X-Solr-Calling-LockId header into the request
context.
Guarding the constructor alone means a V2 call routed this way proceeds with no
calling-lock-id. A future nested locked call could then try to take a lock its
parent already holds, trading a loud NPE for a quiet hang.
Better fix: build a real SolrQueryRequest for the ADMIN_OR_REMOTEPROXY path in
V2HttpCall before invoking Jersey, preserving query-string params and the
calling-lock-id header, rather than passing null through and papering over it
downstream. Keeping a constructor-level null-check too, as defense in depth.
> 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
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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]
