nick-boss-tech opened a new pull request, #5265: URL: https://github.com/apache/solr/pull/5265
🤖 *AI text below* 🤖 *(reviewed by Nick Shanin)* **Draft status: this PR is a draft due to the open-PR limit on my side; the work is complete and ready for review.** Eric Pugh asked for this PR on [SOLR-16398](https://issues.apache.org/jira/browse/SOLR-16398) as the representative collection command, to tune against `dev-docs/apis-v2-conventions.adoc` before the approach scales up to the remaining commands. ## What happens today **Split shard is still served by an annotated v1-style API class while the shard APIs around it are JAX-RS resources.** `SplitShardAPI` carries the v2 route as annotations on a v1-shaped class registered through `CollectionsHandler.getApis()`. The neighboring shard APIs (create shard, delete shard) are Jersey resources with endpoint interfaces in `solr/api`, typed request bodies, and generated SolrJ clients. The v2 tracking spreadsheet lists split shard as not yet migrated to JAX-RS. ## What this change does **Split shard moves to a JAX-RS resource that submits the same overseer message as the v1 command.** - New endpoint interface `SplitShardApi` (`POST /collections/{collectionName}/shards/{shardName}/split`) and typed `SplitShardRequestBody` in `solr/api`, following the command-API path shape in the conventions doc. - New `SplitShard` Jersey resource replacing `SplitShardAPI`; it validates the path parameters and submits the `SPLITSHARD` overseer message through `AdminAPIBase.submitRemoteMessageAndHandleResponse`, returning `SubResponseAccumulatingJerseyResponse` as the conventions doc prescribes for overseer-driven APIs. - The endpoint's request body carries `@RequestBody(description = "Contains user provided parameters")`. A bare `@RequestBody` silently drops the body from the generated OpenAPI spec; with the bare form the generated `ShardsApi.SplitShard` client had no way to send `numSubShards` or any other split parameter. The described form follows `BalanceReplicasApi` and generates a complete client. - The v1 `/admin/collections?action=SPLITSHARD` route is unchanged; the v1 handler case now points at the v2 resource in its javadoc, as with earlier migrations. ## Proof **The new dedicated test passes at the PR head; on the base code the v2 route and the test class do not exist.** - `SplitShardAPITest` (new, dedicated to this API, driving the generated SolrJ client per the conventions doc's testing section): 2 tests run, 0 failures (a successful split through the generated client, and a missing-collection call surfacing as a RemoteSolrException). - `TestCollectionAPIs`: passes with the split-shard assertions removed, since the annotated class they exercised is gone. - The annotated-API mapping test for shards (`V2ShardsAPIMappingTest`) covered only this API and is removed with it. - Verified 2026-10-29 at head `6c56a18236`: tidy clean, Error Prone compile passes, the tests above pass. ## A choice to confirm **Should the per-API generated-client test be the template as this scales up?** Context: the conventions doc's testing section favors a dedicated test class per API, exercising the real HTTP stack through the generated SolrJ client, over the older shared mapping tests. This PR follows that: `SplitShardAPITest` replaces this API's share of the mapping and integration tests. The deciding considerations, in order: does the test exercise the endpoint the way a client user will, including the generated client itself? Does it fail when the route or the body handling breaks? Is it cheap enough to repeat for every remaining command? I recommend yes: the generated-client test caught the request-body defect above during preparation, which the older test styles would not have. If you would rather keep the shared integration test shape for the remaining commands, I will adjust before scaling up. ## Limits **Only split shard is in this PR.** Move replica, rebalance leaders, and migrate docs are implemented and tested on their own branches and follow as separate PRs once this one's shape is settled, per the plan on the ticket. The sibling branches' endpoints carry the same bare `@RequestBody` defect fixed here; each gets the same one-line fix in its own PR. The core commands and the reindex migration are likewise ready on branches for later PRs. Replication is not covered here: Jalaz Kumar is carrying those APIs forward, per the ticket discussion. *AI-generated description. 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]
