nick-boss-tech opened a new pull request, #5266: URL: https://github.com/apache/solr/pull/5266
🤖 *AI text below* 🤖 *(reviewed by Nick Shanin)* ## What happens today **A v2 collection request served by a node that does not host the collection ignores `wt` and answers JSON, which SolrJ's default client rejects.** For a collection path with no local core, `V2HttpCall` takes the remote-proxy early return before any `SolrQueryRequest` is created. The Jersey resource runs locally and succeeds, but [`MediaTypeOverridingFilter`](https://github.com/nick-boss-tech/solr/blob/86d86e3d3e54230b5f3e7b6aa758a189b3b2ed6b/solr/core/src/java/org/apache/solr/jersey/MediaTypeOverridingFilter.java) has no request to read `wt` from and defaults the response to JSON. SolrJ's default parser does send `wt=javabin`, so the call fails with "Expected mime type in [application/vnd.apache.solr.javabin, application/octet-stream] but got application/json". Collection reload is the case reported on this ticket; any v2 collection operation answered by a non-hosting node with a non-JSON `wt` hits it. There is a second failure behind the first: when a writer is selected for this path, it dereferences the missing request and throws a NullPointerException, so the error itself cannot be written in the requested format either. ## What this change does **The response layer falls back to the request parameters the server already parsed, so the requested format is honored and writable on the non-hosting path.** - `MediaTypeOverridingFilter`: when the context carries no `SolrQueryRequest`, the filter reads `wt` from the already-parsed `SOLR_PARAMS` context property instead of defaulting to JSON. - [`MessageBodyWriters`](https://github.com/nick-boss-tech/solr/blob/86d86e3d3e54230b5f3e7b6aa758a189b3b2ed6b/solr/core/src/java/org/apache/solr/jersey/MessageBodyWriters.java): `BaseMessageBodyWriter` builds a `SolrQueryRequestBase` from `SOLR_PARAMS` when the context has no request, so the javabin, XML, and CSV writers work on this path instead of throwing a NullPointerException. - Tests: a new `V2ApiIntegrationTest.testReloadHonorsWtOnNonHostingNode` reloads a collection through a node that hosts no replica of it using the default parser, and `MediaTypeOverridingFilterTest` covers the parameter fallback directly. - No routing, servlet, or request-body handling changes; the hosting-node path is untouched. ## Proof **The new tests pass at the PR head and fail against the parent code with the reported error.** Verified at head `86d86e3d3e`: tidy clean, Error Prone compile passes, `MediaTypeOverridingFilterTest` 8 tests pass, `V2ApiIntegrationTest` 14 tests pass including the new non-hosting reload test, `:solr:core:check -x test` passes, and the root `check -x test` passes. As a control, with only the filter change reverted to the parent version, the new filter test fails and the integration test fails from the non-hosting node with the exact "Expected mime type ... but got application/json" error, while the hosting node's request in the same test passes. ## A choice to confirm **Fix at the response layer, as here, or initialize a full request on the remote-proxy path?** The alternative is to make `V2HttpCall` build a `SolrQueryRequest` before the early return, so every downstream consumer sees a request. That touches the request lifecycle of every v2 collection call, including the ones that work today, to fix a symptom that appears only when the response is written. The parsed parameters are already present in the context on this path, and both places that fail only need those parameters. I recommend the response-layer fix in this PR: it is confined to the two components that fail, and the hosting path is unchanged. If you would rather see the request initialized upstream, I will rework it. ## Limits **Only the non-hosting response path changes.** Requests with a `SolrQueryRequest`, which is every hosting-node and core-level call, behave exactly as before. This PR does not settle `wt` versus `Accept` precedence (SOLR-10998) and does not take up the proposal to remove `wt` (SOLR-18483). SOLR-17086 is a related report in the same filter family and is not addressed here. One practical note: PR #5265 (the split shard migration) names this fix in its limits, because the migrated endpoint answers the default javabin client correctly from every node only once this lands; its own tests use the typed JSON parser and are unaffected either way. *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]
