SOLR-18347: Fix five Admin UI defects found by Selenium

[NextbrickInc]

https://issues.apache.org/jira/browse/SOLR-18347

Description

Fixes all five Admin UI defects listed in SOLR-18347:

1. Per-collection navigation can intermittently invoke showCore() with a null core and throw a TypeError.
2. The Collections screen fails to load when the generated JavaScript client bundle is unavailable.
3. Schema Designer can race schema preparation/persistence against analysis requests.
4. Core overview ping returns HTTP 503 when no healthcheck file is configured.
5. Collection reload success feedback disappears after one second.

Solution

• Guard showCore() until a core object is present, and remove the Selenium console-error exemption for this failure.
• Incorporate the generated-client integration from current main: build and package the bundle into the WAR and serve it to Selenium tests so solrApi is available when Collections and the other V2 screens initialize.
• Disable Analyze while Schema Designer preparation is running, and route Luke requests through the temporary collection so they reach its active replica.
• Return HTTP 200 with status: "not_configured" for ping status when no healthcheck is configured, and handle every ping status explicitly in Core Overview so that enabled/disabled keep the working toggle while not_configured (and any unknown value) show a message instead of a control that would answer 503.
• Keep collection reload success or failure feedback visible after the request completes.
• Add an unreleased changelog entry and update Admin UI test documentation.

Tests

Current revision — 9b5545ddb4

• Full Admin UI Selenium suite, ./gradlew :solr:webapp:test -Ptests.selenium=true against headless Chrome: 53 tests across 18 suites, 0 failures, 0 skipped. This is the whole solr:webapp module, not a targeted subset, and it includes AdminUiSchemaDesignerTest now that its @AwaitsFix is gone.
• ./gradlew tidy: clean, no files modified.
• PingRequestHandlerTest: 6 tests passed.
• JavaScript syntax validation passed with the bundled Node.js 25.0.0 runtime.

Note that the Selenium suites are opt-in behind -Ptests.selenium=true; without the flag :solr:webapp:test reports "6 tests, 6 skipped", which looks like a pass but exercises nothing.

Earlier revisions

• The previous pull-request revision passed the Admin UI browser tests, Gradle precommit check, changelog validation, and labeler jobs.
• The previous Solr Tests via Crave job was cancelled by infrastructure after 41 minutes while ./gradlew test was still running; no test failure was logged.
• Workflows for 9b5545ddb4 are awaiting Apache maintainer approval; labeler has run and passed.

Checklist

• I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
• I have created a Jira issue and added the issue ID to my pull request title.
• I have given Solr maintainers access to contribute to my PR branch.
• I have developed this patch against the main branch.
• The current ./gradlew check workflow is awaiting maintainer approval. It passed on the previous revision.
• I have added tests for my changes.
• I have added documentation for the Reference Guide. (Not applicable to these Admin UI bug fixes.)
• I have added a changelog entry.

[Copilot]

Pull request overview

Fixes an intermittent Admin UI navigation error where the core selector’s ng-change could invoke showCore() with a null/undefined model while the shared menu is still resolving, previously causing a TypeError when reading core.name. The change is localized to the AngularJS controller and tightens Selenium console-error checking so the regression is no longer silently ignored.

Changes:

• Add a null guard in MainController.$scope.showCore(core) before dereferencing core.name and updating the route.
• Remove the Selenium test exemption that filtered out the "reading 'name'" / "showCore" console error so failures are surfaced.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
solr/webapp/web/js/angular/app.js	Guards showCore() against null/undefined core objects before routing.
solr/webapp/src/test/org/apache/solr/webapp/AdminUiTestBase.java	Removes the allowlist filter that previously ignored the showCore null-core console error.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[janhoy]

Can you update PR title and description to match all five fixes?

[NextbrickInc]

Thanks Jan — Yes I can . I updated the PR title and description to cover all five fixes. I also included the updated validation results: 22 Selenium tests across five browser-test classes, six ping-handler tests, and the changelog entry.
Please let me know if you need anything else Sir.

[NextbrickInc]

@janhoy I merged the latest main, resolved the conflicts in collections.js and services.js, and pushed commit aa5f5880ac. GitHub now reports the branch as conflict-free and mergeable.

Validation on the resolved tree:

• ./gradlew tidy passed.
• JavaScript syntax checks passed.
• PingRequestHandlerTest: 6 tests passed.
• Targeted Admin UI Selenium suite: 22 tests passed in Google Chrome.

The five GitHub Actions workflows are currently awaiting maintainer approval before they can run. The previous Crave run was cancelled by infrastructure while ./gradlew test was still running; its logs contain no test failure.

[janhoy]

A bit confusing to lump five fixes into one PR, but I'll not ask you to split them now. See comments

[NextbrickInc]

A bit confusing to lump five fixes into one PR, but I'll not ask you to split them now. See comments

SOLR-18347-fix-report-secure.pdf
pls find attached pdf also . i attached in jira ticket forgot to attach here.
i will reply to your comments.

[NextbrickInc]

Thanks for going through it, @janhoy.

On the packaging point — fair, and I would have split it if I could have. The five came out of one run: they are what the new Selenium suite reported the first time it ran without exemptions. Three of them are coupled through a single file, because AdminUiSchemaDesignerTest's @AwaitsFix and AdminUiTestBase's console-error filters were what had been hiding them, and removing those is what surfaced the failures. Splitting after the fact would leave a window where the suite is green only because the exemptions are still in place. If you would still rather have them apart, the clean seam is PingRequestHandler + Core Overview (defect 4, the only server-side change) against the four Admin UI-only fixes — say the word and I will carve it that way.

I have answered all three inline comments. One of them turned into a change: 9b5545d makes the ping status handling in core-overview.js name its three known states explicitly, so an unknown value no longer renders an "enable ping" control that could not work. Behaviour for enabled, disabled and not_configured is unchanged.

Validation for that commit: the full Admin UI Selenium suite with -Ptests.selenium=true against headless Chrome — 53 tests across 18 suites, 0 failures, 0 skipped.

[NextbrickInc]

SOLR18347_PR4818_Review_Response_NextBricks_Shrey_Narayan.pdf

@janhoy

[epugh]

BTW, if there is a lot of flakiness in this test, I am getting closer to migrating the Admin UI to using the generated V2 Javascript client, which I think is more reliable. And honestly, I think i might have made some commits that may even have broke the schema-designer.js now that I think of it (not sure), so it may be okay to not worry about this page... It's on my list to get to "done done'!

[NextbrickInc]

Thanks @epugh — two things that might change the calculus.

It isn't flaky any more. The @AwaitsFix blamed "transient failures at automation speed"; the
real cause was deterministic. The designer addressed Luke by core name, and a core name only
resolves on the node hosting it — with configureCluster(2), that's the wrong node about half the
time. Addressing the collection fixes it: 53 tests, 18 suites, 0 failures.

Your hunch is right. SchemaDesignerResponse.core came in with SOLR-18152 (#4203), commented
"Active replica core name ... used for Luke API calls" — reasonable-looking, just not routable
from an arbitrary node. Nothing else in that migration looks affected; every Schema Designer
assertion passes on top of it.

So I'd keep the test rather than drop the page — it's what would have caught this. And the V2
client would issue the same request against the same core name, so this class of bug survives the
migration either way.

---

Status — I think this is ready to go in.

• @janhoy's three comments are answered; the one that needed a change is pushed as 9b5545ddb4.
• Full Admin UI Selenium suite: 53 tests, 18 suites, 0 failures, 0 skipped. tidy clean,
  PingRequestHandlerTest 6/6.
• No open review threads and nothing outstanding on my side.

@janhoy — the only reservation you raised was the five-in-one packaging. If you're willing to take
it as-is, I'd appreciate an approval. If not, say so and I'll split it along
PingRequestHandler + Core Overview vs. the four UI-only fixes today.

@epugh — if the Schema Designer question above is settled for you, a second approval would let this
land.

[NextbrickInc]

Pls approve PR, merge code. Thank you so much .

[NextbrickInc]

SOLR18347_PR4818_Review_Response_NextBricks_Shrey_Narayan.pdf

[janhoy]

Pls approve PR, merge code. Thank you so much .

Thanks for the PR! Just so you know what to expect: Solr is a global volunteer project, so we usually leave a PR open for at least three days before merging, to give other committers a chance to review.

Reminders are welcome once a PR has gone quiet — say after a week with no activity. Thanks for your patience in the meantime!