NextbrickInc commented on code in PR #4818:
URL: https://github.com/apache/solr/pull/4818#discussion_r3870765064
##########
solr/webapp/web/js/angular/controllers/schema-designer.js:
##########
@@ -451,9 +455,11 @@ solrAdminApp.controller('SchemaDesignerController',
function ($scope, $timeout,
// re-apply the filters on the updated schema
$scope.onTreeFilterOptionChanged();
- // Load the Luke schema
- Luke.schema({core: data.core}, function (schema) {
- Luke.raw({core: data.core}, function (index) {
+ // Route Luke through the temporary collection so the request reaches its
+ // active replica even when the Admin UI is connected to a different node.
+ var lukeTarget = data.tempCollection || data.core;
Review Comment:
By the Selenium test — it is what the console-error exemption was hiding.
Before this PR the test was `@AwaitsFix(bugUrl = ".../SOLR-18347")`, retried
`#analyze` in a loop while dismissing error dialogs, and finished with
`assertNoSevereConsoleErrors("schema-designer/", "._designer_")` — a filter for
exactly the designer's own temp-collection URLs
(`SchemaDesignerConstants.DESIGNER_PREFIX = "._designer_"`). Dropping that
filter is what made the failure visible.
The mechanism is a core-name vs collection-name mismatch.
`SchemaDesigner.java:1241-1251` returns both:
```java
DocCollection coll = zkStateReader().getCollection(mutableId);
Collection<Slice> activeSlices = coll.getActiveSlices();
if (!activeSlices.isEmpty()) {
response.core =
activeSlices.stream().findAny().orElseThrow().getLeader().getCoreName();
}
...
response.tempCollection = mutableId;
```
`response.core` is a **core** name, and a core name only resolves on the
node that hosts it. `AdminUiTestBase` runs `configureCluster(2)`, so the temp
collection's leader lands on the node *not* serving the Admin UI roughly half
the time and `GET /solr/._designer_xyz_shard1_replica_n1/admin/luke` 404s —
which is precisely the intermittency that put this test under `@AwaitsFix`.
Addressing the **collection** lets Solr route to an active replica from any
node.
Worth noting too: `response.core` is only assigned when a slice is active,
so the old code could build `/solr/undefined/admin/luke`. The `|| data.core`
fallback preserves the previous behaviour wherever `tempCollection` is absent.
So it is a genuine multi-node bug rather than a test artifact — any
SolrCloud deployment where the browser is pointed at a node that does not host
the temp replica hits it. It simply had no automated coverage until the suite
stopped excusing it.
##########
solr/webapp/web/js/angular/app.js:
##########
@@ -653,7 +653,9 @@ solrAdminApp.controller('MainController', function($scope,
$route, $rootScope, $
}
$scope.showCore = function(core) {
- $location.url("/" + core.name + "/core-overview");
+ if (core) {
+ $location.url("/" + core.name + "/core-overview");
Review Comment:
Yes — defect 1 in SOLR-18347.
The evidence that matters is not the guard itself but the exemption it lets
us delete from the shared test base:
```java
// solr/webapp/src/test/org/apache/solr/webapp/AdminUiTestBase.java
- // benign race in the shared menu code: showCore() fires with a null core
- // while the per-collection menu resolves after navigation
- .filter(
- entry ->
- !(entry.getMessage().contains("reading 'name'")
- && entry.getMessage().contains("showCore")))
```
Every Admin UI Selenium test was globally swallowing `Cannot read properties
of null (reading 'name')` raised from `showCore`. With the guard in place that
filter is gone, so a recurrence now fails the suite instead of being ignored.
--
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]
