janhoy opened a new pull request, #4800: URL: https://github.com/apache/solr/pull/4800
https://issues.apache.org/jira/browse/SOLR-8474 # Description `AdminUiSecurityAuthTest.testLoginAndSecurityScreen` was reported flaky in CI ([example failure](https://github.com/apache/solr/actions/runs/32601007812/job/97099140064?pr=4718)): `Timed out waiting for page to contain: uitestrole`, even though the test had already confirmed via the authorization API that the role existed. The failure artifacts (page source captured at failure time) show the users table containing `uitestuser` with **no roles** and no `uitestrole` anywhere — so the backend had the role, but the UI tables never showed it. This turned out to be a real bug in the Security screen, not just a test problem: Security config updates are persisted to ZooKeeper and each node reloads them **asynchronously** (watch-driven), so a GET issued right after a POST can still return the previous config. After `doUpsertRole` the controller refreshed the tables with a single immediate GET; when that GET raced the reload, the stale tables were rendered and never refreshed again. The controller already acknowledged this race in other paths with hacks ("TODO: shouldn't need this extra GET ... seems to avoid what looks like a race", "avoids a weird race with not getting the latest config after an update") — an extra GET just adds latency and doesn't close the race. Notably, the CI failure hit the *role* path, the only write path that had no hack at all. # Solution In `security.js`, add a `whenReflected(path, check, done)` helper that polls the security endpoint (250ms interval, bounded at ~10s, falling back to a plain refresh) until the just-made change is visible on the node, and only then refreshes the panel. Applied to all write paths: add/edit user, delete user, add/edit role (including per-permission grants), add/update/delete permission, and the `blockUnknown`/`forwardCredentials` toggles (where a stale refresh visibly reverted the radio button). The two "extra GET" hacks are replaced by this deterministic wait. Drive-by fixes in the same controller, found while analyzing: - `doUpsertRole`'s error path referenced an undefined `username` variable (ReferenceError that would have broken the error dialog). - In `doUpsertPermission`, the params loop's `var name` shadowed (function-scoped, so actually overwrote) the outer permission `name`, corrupting later error messages for custom permissions with params. - The per-permission loop in `doUpsertRole` captured the loop variable with `var`; async callbacks now capture the correct `permName` via `let`. - `refreshSecurityPanel` reuses the new `findBasicAuthn` helper instead of inlining the multi-auth scheme lookup. In the test, the login fields now use the retrying `setText` helper from `AdminUiTestBase` instead of raw `clear()`/`sendKeys()` on a held element, tolerating Angular re-renders mid-interaction. # Tests - Beasted `AdminUiSecurityAuthTest` locally with `-p solr/webapp beast -Ptests.dups=10 -Ptests.selenium=true`: 5/5 green before the change (the race needs a loaded machine to trigger), 10/10 green after. - Full `:solr:webapp:test -Ptests.selenium=true` suite run green with the change. No changelog entry: test-infrastructure/UI hardening under the existing SOLR-8474 umbrella. # Checklist - [x] I have reviewed the guidelines for [How to Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) - [x] I have given Solr maintainers access to contribute to my PR branch - [x] I have developed this patch against the `main` branch - [x] I have run `./gradlew check` (scoped to the module) - [x] I have added tests for my changes (existing selenium test hardened) -- 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]
