epugh commented on PR #5241: URL: https://github.com/apache/solr/pull/5241#issuecomment-6441527346
Thanks for the report, @nick-boss-tech. I reviewed the diff from `solr-16398-submit` directly (didn't merge it) and went with a smaller, independently-written and tested version instead: `d501766df83`. A couple of things that came up while implementing/testing it: - The proposed fix routed *every* replication-fetch failure through `ApiErrorHandler`, dropping the inline "Replication is not configured" message entirely. I kept that message for the default case and only special-case 401/403 - a blanket swap loses useful context for the common failure modes that aren't auth-related. - To actually test this I had to fault-inject responses (a scoped servlet filter forcing 403/503 on just this core's `/replication` call), since a plain `_default`-configset core's `/replication` handler is implicit and returns 200 by default rather than 404ing - good to confirm empirically rather than assume. - Along the way I found a separate, pre-existing bug unrelated to this PR: `app.js`'s global `$http` interceptor's `ended()` handler unconditionally clears `$rootScope.showAuthzFailures` on *every* successful v1 `$http` call. `core-overview.js`'s `refresh()` fires several v1 calls concurrently (Luke, CoreInfo, Ping) alongside the replication fetch, so a 403 on replication can have its permission banner immediately clobbered by one of those unrelated successes landing after it. That's a cross-cutting issue in the shared interceptor, not something to fix inside this PR - worth its own JIRA if someone wants to track it down (I don't have a Jira account handy to file it myself). New test: `AdminUiCoreOverviewReplicationErrorsTest`, covering both the generic-failure and 401/403 paths with real fault injection rather than assertions on the (racy) global banner. -- 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]
