nick-boss-tech opened a new pull request, #5010: URL: https://github.com/apache/solr/pull/5010
🤖 *AI text below* 🤖 *(posted on behalf of Nick Shanin)* https://issues.apache.org/jira/browse/SOLR-12998 When recovery is requested for a core that is still loading, REQUESTRECOVERY used to answer 400 "Unable to locate core", the same response as for a core that does not exist, so the recovery request was dropped as invalid even though the core was about to become available. This change separates the two cases: - `CoreAdminOperation` returns 503 with the message "Core <name> is still loading" when the core exists but has not finished loading; an unknown core still gets a 400. - `SyncStrategy` retries the recovery request when it gets that response: up to three attempts total, 30s apart. The retry is scoped to the exact signal: the response must be a 503 carrying the still-loading message. Any other 503 (a proxy error, or a different failure on the replica) is logged and dropped after one attempt, like any other failure. An `Error` from any attempt is rethrown rather than logged and swallowed. The retry loop sits in a package-visible static method that takes the sender and the delay, so the new `SyncStrategyTest` covers it without a cluster and without sleeping 30s: still-loading then success, exhaustion at three attempts, no retry for another 503, `Error` propagation from the first attempt and from a retry, and closed/interrupt behaviour. `CoreAdminOperationTest` covers the 503/400 split and pins the 503 message text. Tests: `SyncStrategyTest` and `CoreAdminOperationTest` pass (54 tests), Error Prone clean, `:solr:core:check -x test` passes. Changelog: `changelog/unreleased/SOLR-12998.yml` (fixed) ### AI assistance AI agents assisted with research, implementation, review, and drafting. Nick Shanin directed the work and takes responsibility for this contribution. -- 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]
