You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "janhoy (via GitHub)" <gi...@apache.org> on 2026/08/23 17:51:17 UTC

[PR] SOLR-18400: Plugins screen 500s when metrics are disabled [solr]

janhoy opened a new pull request, #4803:
URL: https://github.com/apache/solr/pull/4803

   https://issues.apache.org/jira/browse/SOLR-18400
   
   When metrics collection is disabled, `MetricsHandler` adds an `error` entry instead of `metrics`, and `PrometheusResponseWriter` threw `IOException("No metrics found in response")` → HTTP 500 and a blank Plugins screen.
   
   - `PrometheusResponseWriter` now writes the error as a Prometheus comment (`# metrics collection is disabled`) with HTTP 200 — matching the old JSON-era behavior and keeping the response a valid exposition
   - Plugins screen shows an explanatory message instead of a blank page
   - New regression test `TestPrometheusResponseWriterMetricsDisabled` (cloud cluster, metrics off by default)
   
   Verified with the Selenium Admin UI tests (SmokeTest + CollectionScreensTest, 11 tests) from the `admin-ui-selenium-tests` branch merged locally, and `gradlew precommit`.


-- 
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: issues-unsubscribe@solr.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org


Re: [PR] SOLR-18400: Plugins screen 500s when metrics are disabled [solr]

Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on PR #4803:
URL: https://github.com/apache/solr/pull/4803#issuecomment-5387652704

   Note: the v2 metrics API (`GetMetrics`) still throws a 510 `INVALID_STATE` error when metrics collection is disabled, so v1 and v2 now behave differently (v1 returns 200 with a `# metrics collection is disabled` comment). I left v2 as-is since this PR targets the v1 endpoint the Admin UI uses, but we may want to align v2 with the same graceful behavior in a follow-up.


-- 
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: issues-unsubscribe@solr.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org


Re: [PR] SOLR-18400: Plugins screen 500s when metrics are disabled [solr]

Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on PR #4803:
URL: https://github.com/apache/solr/pull/4803#issuecomment-6038178551

   I think I like HTTP 510 better in general, so I vote for having both v1 and v2 APIs err with HTTP 510 when metrics are disabled. And adapt frontend to cope.


-- 
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: issues-unsubscribe@solr.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org


Re: [PR] SOLR-18400: Plugins screen 500s when metrics are disabled [solr]

Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy merged PR #4803:
URL: https://github.com/apache/solr/pull/4803


-- 
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: issues-unsubscribe@solr.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org


Re: [PR] SOLR-18400: Plugins screen 500s when metrics are disabled [solr]

Posted by "epugh (via GitHub)" <gi...@apache.org>.
epugh commented on PR #4803:
URL: https://github.com/apache/solr/pull/4803#issuecomment-6044857926

   Interestingly I was just poiking at the SQL UI in the admin tool, if you don't enable the module you get an error when you run a sql query.   I modified it to catch the classcast exception "no SQLHandler found" and then show a nice message about enabling the module.   I first thought hoguht "hey, can I consult which plugins/endpoints are avialable via v2 apis" and was going to see if the /sql existed or not.   BUt that API doesn't exist.   SO I went with the narrower fix.   
   
   I wonder if we should return 510 instead of a classcast exception if you hit /sql and it can't load?   


-- 
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: issues-unsubscribe@solr.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org


Re: [PR] SOLR-18400: Plugins screen 500s when metrics are disabled [solr]

Posted by "epugh (via GitHub)" <gi...@apache.org>.
epugh commented on PR #4803:
URL: https://github.com/apache/solr/pull/4803#issuecomment-5395969627

   > Note: the v2 metrics API (`GetMetrics`) still throws a 510 `INVALID_STATE` error when metrics collection is disabled, so v1 and v2 now behave differently (v1 returns 200 with a `# metrics collection is disabled` comment). I left v2 as-is since this PR targets the v1 endpoint the Admin UI uses, but we may want to align v2 with the same graceful behavior in a follow-up.
   
   It would make life easier when we move if V2 did the same as V1...   One reason I'm axinous to get us to V2 everywhere we can is that we've seen this pattern of fixes making it to V1 when we also have V2, and then it falls behind...


-- 
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: issues-unsubscribe@solr.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org


Re: [PR] SOLR-18400: Plugins screen 500s when metrics are disabled [solr]

Posted by "Copilot (via GitHub)" <gi...@apache.org>.
Copilot commented on code in PR #4803:
URL: https://github.com/apache/solr/pull/4803#discussion_r3839213477


##########
solr/webapp/web/partials/plugins.html:
##########
@@ -17,6 +17,9 @@
 <div id="plugins" class="clearfix">
 
   <div id="frame">
+      <div class="message-container" ng-show="metricsDisabled">
+        <div class="message">Metrics collection is disabled on this node, so no plugin information is available. Start Solr with metricsEnabled=true to enable it.</div>

Review Comment:
   `metricsEnabled` is not read by the shipped `server/solr/solr.xml`; the enabled value is taken from the `<metrics enabled="...">` attribute (`SolrXmlConfig.java:682-688`). A user who disabled metrics in `solr.xml` and follows this message will restart with this property and remain disabled. Please point to enabling the setting in `solr.xml` (or otherwise describe the actual configured mechanism).



##########
solr/core/src/java/org/apache/solr/response/PrometheusResponseWriter.java:
##########
@@ -63,6 +63,13 @@ public void write(
     // Otherwise handle MetricSnapshots
     var metrics = response.getValues().get("metrics");
     if (metrics == null) {
+      // No snapshots available, e.g. when metrics collection is disabled. Emit the reason as a
+      // comment so the response is still a valid Prometheus exposition
+      var error = response.getValues().get("error");
+      if (error != null) {
+        out.write(("# " + error + "\n").getBytes(StandardCharsets.UTF_8));
+        return;
+      }

Review Comment:
   OpenMetrics requests also reach this branch (`writeOpenMetricsFormat` is selected by `wt=openmetrics` or the Accept header), but this body stops after the comment. Unlike Prometheus, OpenMetrics requires a final `# EOF` marker (the existing tests assert this for normal OpenMetrics responses), so disabled-metrics responses are invalid. Append `# EOF` when the request is OpenMetrics and cover that format.



-- 
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: issues-unsubscribe@solr.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org


Re: [PR] SOLR-18400: Plugins screen 500s when metrics are disabled [solr]

Posted by "Copilot (via GitHub)" <gi...@apache.org>.
Copilot commented on code in PR #4803:
URL: https://github.com/apache/solr/pull/4803#discussion_r4207239461


##########
solr/webapp/web/js/angular/app.js:
##########
@@ -429,6 +429,9 @@ solrAdminApp.config([
     // Schema Designer and Security panels handle errors internally to provide a better user experience than the global error handler
     var isHandledBySchemaDesigner = rejection.config.url && rejection.config.url.startsWith("/api/schema-designer/");
     var isHandledBySecurity = rejection.config.url && rejection.config.url.startsWith("/api/cluster/security/");
+    // HTTP 510 means a feature is switched off in solr.xml, e.g. metrics collection. The screen
+    // asking for that data explains it in place, so skip the global error banner.
+    var isDisabledFeature = rejection.status === 510;

Review Comment:
   `INVALID_STATE` is Solr's general HTTP 510 code, not a feature-disabled-only status (for example, `SplitShardCmd` uses it when a parent slice is not active and `HttpSolrCall` uses it when no active replica is found). Suppressing the global error handler for every 510 therefore makes unrelated `$http` failures disappear instead of populating `$rootScope.exceptions`; restrict this check to the metrics request (or use an endpoint-specific marker).



##########
solr/webapp/web/js/angular/controllers/plugins.js:
##########
@@ -44,6 +45,12 @@ solrAdminApp.controller('PluginsController',
                 } else {
                     $scope.plugins = [];
                 }
+            }, function (response) {
+                // Solr answers HTTP 510 when metrics collection is turned off in solr.xml
+                $scope.metricsDisabled = response.status === 510;
+                $scope.types = [];
+                $scope.type = null;
+                $scope.plugins = [];

Review Comment:
   The new 510 path is not covered by the existing Admin UI tests: `AdminUiCollectionScreensTest` only exercises the Plugins screen with metrics enabled, and `AdminUiTestBase` explicitly sets `metricsEnabled` to true. Add a browser test using a metrics-disabled node/config that asserts the explanatory message is rendered and no global error banner is recorded; the backend `MetricsDisabledTest` alone cannot catch regressions in this controller/template path.



-- 
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: issues-unsubscribe@solr.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org


Re: [PR] SOLR-18400: Plugins screen 500s when metrics are disabled [solr]

Posted by "janhoy (via GitHub)" <gi...@apache.org>.
janhoy commented on PR #4803:
URL: https://github.com/apache/solr/pull/4803#issuecomment-5581142875

   The 510 code used by v2 looks a bit off, although I understand the intent behind it, it is better than a 503 which could signal that the entire Solr node is unavailable.
   
   Prometheus scraping an endpoint will interpret any non-200 code as "solr scrape target unavailable" and flag it as `DOWN`.  A 200-code with empty response will be interpreted as "solr scrape target functioning, but no data" and flag it as "UP".
   
   You can argue both ways. But agree v1 and v2 shuold probably be aligned. I'm not opposed to instead align v1 with HTTP 510 and adapt frontend to detect this as a "metrics disabled" signal instead of text parsing?


-- 
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: issues-unsubscribe@solr.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org


Re: [PR] SOLR-18400: Plugins screen 500s when metrics are disabled [solr]

Posted by "epugh (via GitHub)" <gi...@apache.org>.
epugh commented on PR #4803:
URL: https://github.com/apache/solr/pull/4803#issuecomment-5574594551

   @janhoy I think this was very close, so I updated it from main.   I am also responding to a copilot item!
   
   One question, are you suggesting that the 501 is a nicer way of handling this situation versus the current string matching approach?   If so, I am also wondering if you are suggesting that we look at lots of apis through the lens of "this is a good time to throw a 501 error" and maybe make the a consistent pattern in our V2 apis?  Or am I reading too much into this.
   
   Lastly, I wonder how far our V2 GetMetrics is from being usable int eh admin ui instead of hte v1?


-- 
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: issues-unsubscribe@solr.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org