wouldn't we want to manipulate the sort spec so that we get all docs up to offset (AKA "start" param) + rows since RRF/combiner is going to want to see all docs/rankings up to offset+rows? Otherwise our combiner is blind to the "offset" docs. Assuming you agree, then we need to basically apply paging at this layer (our component) instead of letting the subquery do it.

It anyways happening here

That's for distributed-search but not single-core search.

I think user-managed/standalone vs SolrCloud is orthogonal. This is about a single shard working correctly (in whatever Solr mode). IMO it's not optional for basic paging parameters to work correctly with one shard.

I could imagine we'd prefer a mechanism for a SearchComponent to force the "shortCircuit"=false thereby ensuring there's always a distributed phase. Maybe that could be done by re-ordering SearchHandler's call to getAndPrepShardHandler to be after prepareComponents (swap adjacent lines)? Then the prepare method of this component could force distrib and add the shortCircuit=false or something like that. And/or maybe a component should have a more elegant callback to communicate that it forces distributed search (even when there's one shard/core). This would overall simplify this component, no longer needing to handle paging in process(); instead do for distributed-search only.

I think it's a bit sneaky that a predicate looking method has a side-effect. This is a hack to work around a need for something proper -- for a component or handler to communicate we need the distributed search algorithm (no so-called short-circuit).

I followed what you said here:
I agree it's a bit sneaky. However, Apologies, but yet I didn't follow the part below:

for a component or handler to communicate, we need the distributed search algorithm (no so-called short-circuit).

afaik, in standalone distributed search, we need the shards value to be passed by the user.

It's not just standalone; a single shard collection will "short-circuit". I was going to link to my same comment. I understand the need/desire. Interestingly, this is the first component to want to prevent the short circuit, but I could see it being useful for any search component author who doesn't want the extra development cost of an optimized single-shard algorithm.

Perhaps if SearchHandler called SearchComponent.prepare before it initialized ShardHandler (that latter part needs to know if short-circuit), then a component could add the short-circuit param.

Makes sense. Have changed the logic in such a way that it can be useful for other search components as well where a distributed request can be forced depending on the component requirement.

Please update this test to not call queryServer since it doesn't compare against the control client. I wish that method came with a big fat disclaimer and was named differently that didn't look so normal. There are probably more callers of it than there should be. I did #3639 just now.

In order for this test to compare both single shard & multi-shard with score relevancy, you could do a couple different things. One is to use the ExactStatsCache for distributed-IDF. Or, write queries that set a constant/fixed score. That would actually be most clear.

With such a test, you don't need to test non-distributed since the test infrastructure here allows you to do both as one.

True, but I also wanted to show the results are not the same as what was expected in a single shard, as I described in the jira issue. Asserting only ideal queries (like constant/fixed score) or a type of queries (lexical with ExactStatsCache) may not give a clear picture to the algorithm IMHO.

This part looks suspicious to me; so shortCircuit=false isn't enough? Did you construct this based on seeing similar code elsewhere (where?) to create a shards URL?

No, shortCircuit=false is not enough as it helps make the rb.isDistrib=false and force the method to not go through the shardHandler requests, rather stick to node local indexes through SearchComponent.process method.
I couldn't find this code anywhere but created myself.

I thought of this as well, yet it feels weird to put a request aspect into the response data holder. It doesn't affect the response. Any way... it's really minor. This is pragmatic.

I'm now confused on how to differentiate the testing approach between this class and DistributedCombinedQueryComponentTest. That one is named appropriately (consistently with other distributed tests) and extends BaseDistributedSearchTestCase. I'm not sure this test has a role/purpose if that one can be comprehensive.

Since, the algorithm doesn't support non-distributed request anymore, it didn't make sense to add test cases by extending SolrTestCaseJ4 so I have changed it. However, this class can be merged with other CombinedQueryTest but the key idea was: The class verifies the functionality of the component by performing few basic queries in single sharded mode and validating the responses including limitations and combiner plugin.

If you feel it should be merged to other test classes, I am open to making those changes when we finalise this one