epugh commented on PR #5265:
URL: https://github.com/apache/solr/pull/5265#issuecomment-6594600652
Nice work on the new JAX-RS `SplitShard` resource — path design, response
typing (`SplitShardResponse extends SubResponseAccumulatingJerseyResponse` with
a typed `timing` field), and the new `submitRemoteMessageAndHandleResponse(...,
timeoutMs)` overload in `AdminAPIBase` all line up well with
`dev-docs/apis-v2-conventions.adoc` and `dev-docs/apis.adoc`.
One gap: `dev-docs/apis.adoc`'s "Overseer-driven (AdminAPIBase) APIs"
section actually gives `SPLITSHARD_OP` as its worked example of the target
v1→v2 delegation pattern:
```java
SPLITSHARD_OP(
SPLITSHARD,
(req, rsp, h) -> {
SplitShardAPI.invokeWithV1Params(h.coreContainer, req, rsp);
return null;
}),
```
But `CollectionsHandler.SPLITSHARD_OP`'s lambda is unchanged here — it still
re-implements the same three cross-parameter validation checks
(`splitKey`+`ranges`, `numSubShards`+either, `splitFuzz`+either) that now also
live in `SplitShard.validateSplitOptions()`, and still returns a `Map<String,
Object>` for `CollectionsHandler`'s generic fallback path, which the doc calls
out as "not an example to follow for new migrations." `SplitShard` also doesn't
expose the two conventional static entry points
(`createRequestBodyFromV1Params`/`invokeWithV1Params`) the doc describes for v1
to call into.
Concretely this means the validation rules are duplicated and can drift, and
v1 traffic (still the dominant path) never exercises the new v2 code. Would it
make sense to wire `SPLITSHARD_OP` through `SplitShard.invokeWithV1Params(...)`
the way `CREATESHARD_OP`/`DELETESHARD_OP` already do for
`CreateShard`/`DeleteShard`? Happy to help sketch that adapter if useful. One
thing to watch per the doc: leave the v2 request body's `async` field unset in
that adapter, since v1's dispatch already wraps the whole call in its own
async-task submission.
--
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]
