nick-boss-tech opened a new pull request, #5031: URL: https://github.com/apache/solr/pull/5031
🤖 *AI text below* 🤖 *(posted on behalf of Nick Shanin)* https://issues.apache.org/jira/browse/SOLR-15823 ## What happens today The companion PR for this ticket gave the V2 logging API a `nodes` parameter on `PUT /node/logging/levels`, so a level change can be broadcast to several nodes at once. The read side did not follow: `GET /node/logging/levels` takes no `nodes` parameter and always answers with the receiving node's own listing. That is a step back from V1, where `GET /admin/info/logging?nodes=all` aggregates every node's levels listing keyed by node name; from V2, an operator or tool that wants the cluster's levels has to call each node itself. This PR is the follow-up to the set-level PR, [#5030](https://github.com/apache/solr/pull/5030): it is stacked on that PR's branch and is meant to land after it. ## What this change does `GET /node/logging/levels` accepts the same `nodes` parameter with the same semantics as the set-level PUT ([NodeLoggingApis.java:34-43](https://github.com/apache/solr/blob/caf3dbf4d8dbf2b0044f09df869e290d51ab26c0/solr/api/src/java/org/apache/solr/client/api/endpoint/NodeLoggingApis.java#L34-L43)). `nodes=all` collects the listing from every live node; a comma-separated list collects it from those nodes. The receiving node does not also serve its own listing locally; it is covered only if the resolved set names it, in which case it calls itself over HTTP. Each node's full listing (watcher, levels, loggers) rides in the response under its node name, and requested nodes that did not respond are named under `failedNodes`. An unknown node name fails the request with a 400 before anything is sent, and `nodes` on a standalone (non-SolrCloud) node is a 400. Without `nodes`, the response is exactly what the endpoint returns today. Under the hood, the broadcast helper the set-level PR adde d is generalized to take any built request ([NodeLogging.java:74-82](https://github.com/apache/solr/blob/caf3dbf4d8dbf2b0044f09df869e290d51ab26c0/solr/core/src/java/org/apache/solr/handler/admin/api/NodeLogging.java#L74-L82), [NodeLogging.java:122-168](https://github.com/apache/solr/blob/caf3dbf4d8dbf2b0044f09df869e290d51ab26c0/solr/core/src/java/org/apache/solr/handler/admin/api/NodeLogging.java#L122-L168)), so both endpoints share one copy of the standalone guard, the unknown-node pre-check, and the `failedNodes` computation. The V1 handler keeps passing `null` for `nodes` ([LoggingHandler.java:91](https://github.com/apache/solr/blob/caf3dbf4d8dbf2b0044f09df869e290d51ab26c0/solr/core/src/java/org/apache/solr/handler/admin/LoggingHandler.java#L91)), so V1 requests serve locally exactly as before. The Admin UI is unchanged; its levels screen keeps reading the local node, as it did under V1. The reference guide's logging page documents the parameter on the listing as well ([configuri ng-logging.adoc:118-124](https://github.com/apache/solr/blob/caf3dbf4d8dbf2b0044f09df869e290d51ab26c0/solr/solr-ref-guide/modules/deployment-guide/pages/configuring-logging.adoc#L118-L124)). ## Proof Verified 2026-10-05 at head caf3dbf4d8db. Premise, new tests against the companion branch's production code (head 100ad2e0df69, where the GET ignores `nodes`): of the four new cases in NodeLoggingNodesSolrCloudTest ([NodeLoggingNodesSolrCloudTest.java](https://github.com/apache/solr/blob/caf3dbf4d8dbf2b0044f09df869e290d51ab26c0/solr/core/src/test/org/apache/solr/handler/admin/api/NodeLoggingNodesSolrCloudTest.java)), the three substantive ones fail for the stated reason. The broadcast-all case finds no `failedNodes` and no per-node entries because the base answers with its local listing; the single-node case likewise; the unknown-node case gets a 200 response instead of the expected 400. The fourth case, which pins today's no-`nodes` response shape, passes there, as it should. At this head: NodeLoggingNodesSolrCloudTest 8/8 (the four set-level cases plus the four levels-read cases above), NodeLoggingAPITest ([NodeLoggingAPITest.java](https://github.com/apache/solr/blob/caf3dbf4d8dbf2b0044f09df869e290d51ab26c0/solr/core/src/test/org/apache/solr/handler/admin/api/NodeLoggingAPITest.java)) 9/9 (including the unchanged local shape and the standalone guard for the GET), LoggingHandlerTest ([LoggingHandlerTest.java](https://github.com/apache/solr/blob/caf3dbf4d8dbf2b0044f09df869e290d51ab26c0/solr/core/src/test/org/apache/solr/handler/admin/LoggingHandlerTest.java)) 1/1. Tidy, Error Prone compile for `:solr:api` and `:solr:core`, and `:solr:api:check` plus `:solr:core:check -x test` all pass. ## Limits The other two logging endpoints do not honor `nodes`: `GET /node/logging/messages` (a node's buffered log history) and `PUT /node/logging/messages/threshold`. Both were scoped alongside this change and left out deliberately; we will open a follow-up ticket and PR for either on request. A broadcast levels read inlines every node's full logger list, hundreds of entries per node, in a single response; there is no paging or summary form. The top-level `levels` and `loggers` fields stay empty under broadcast, the same shape the set-level PR poses for its per-node results. Changelog: `changelog/unreleased/SOLR-15823.yml` (carried over from the companion PR; this PR adds no separate entry) ### AI assistance AI agents assisted with research, implementation, review, and drafting. Nick Shanin directed the work and takes responsibility for this contribution. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
