nick-boss-tech opened a new pull request, #5285: URL: https://github.com/apache/solr/pull/5285
🤖 *AI text below* 🤖 *(reviewed by Nick Shanin)* Jira: [SOLR-16398](https://issues.apache.org/jira/browse/SOLR-16398). This defect was found by the new request-handling coverage on PR #5284: its `testException` expects a 400 from the migrated rebalance-leaders endpoint for a body carrying non-numeric values, and the endpoint answers 500. The same failure reproduces on endpoints already migrated on `main`, so the fix is split out here rather than added to that PR. ## What happens today **A v2 request body that Jackson cannot parse or convert is reported as a 500 server error, although the fault is in the client's request.** When a JSON body carries a value of the wrong type for a request-body field (for example a string where an integer is required), deserialization fails before the resource method runs. The resulting `JsonProcessingException` has no dedicated handler, so it falls through to `CatchAllExceptionMapper` and is answered as a 500. The pre-migration APIs answered the equivalent bad input with a 400. ## What this change does **A new exception mapper reports Jackson body-parsing failures as a 400 in the standard v2 error format, for every v2 endpoint.** [`JsonProcessingExceptionMapper`](https://github.com/nick-boss-tech/solr/blob/e6fbade6773b3bf78e95f50ecc2335276daca651/solr/core/src/java/org/apache/solr/jersey/JsonProcessingExceptionMapper.java) follows the existing [`NotFoundExceptionMapper`](https://github.com/nick-boss-tech/solr/blob/e6fbade6773b3bf78e95f50ecc2335276daca651/solr/core/src/java/org/apache/solr/jersey/NotFoundExceptionMapper.java) pattern: it wraps the failure in a `SolrException` with `ErrorCode.BAD_REQUEST` and the parser's message, and renders it through the same response path as other v2 errors. It is registered alongside the other mappers in `JerseyApplications`. Because the mapping sits in the shared JAX-RS layer, it applies to every v2 endpoint that takes a JSON body, including the endpoints already migrated to JAX-RS on `main` (create collection, split shard) and the ones migrating in sibling PRs (rebalance leaders, migrate docs, move replica). A regression test posts an unconvertible body to the create- collection endpoint and requires a 400. ## Proof **The new test fails with a 500 on the base code and passes with the fix; the surrounding suites stay green.** On the unmodified `main` code, the new `V2ApiIntegrationTest.testUnparseableRequestBody` test fails: the create-collection endpoint returns 500 for `{"name": ..., "replicationFactor": "abc"}`, with an `InvalidFormatException` in the server log. With this change the same requests return 400. Full gate at e6fbade677: tidy clean, Error Prone compile passes, `V2ApiIntegrationTest` passes 14 of 14 (including the new test), `TestApiFramework` 3 of 3, `TestCollectionAPIs` 2 of 2, `JerseyApplicationSharingTest` 1 of 1, `SolrJacksonMapperTest` 3 of 3, and `:solr:core:check -x test` passes. The failing case on PR #5284 (rebalance leaders) exercises the same mapper through the same code path; that PR's test goes green once this change is under it. ## A choice to check **The mapper covers the whole `JsonProcessingException` family, not only type-conversion failures.** Malformed JSON syntax, unknown enum values, and wrong-typed fields all become 400s. That breadth is deliberate: every member of the family is a defect in the body the client sent, and the pre-migration behavior for bad input was a 400. If maintainers would rather scope the mapping more narrowly, the mapper is the single place to narrow it. ## Limits **Only body parsing and conversion failures change status; everything after parsing behaves as before.** Exceptions thrown by resource code after a body has been parsed keep their current handling and status codes. Request bodies in formats that do not pass through Jackson (Javabin, XML) are unaffected. The error message includes the parser's description of the problem (the field and the expected type), matching what the pre-migration APIs surfaced for bad input. *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]
