shaojunying commented on PR #10182: URL: https://github.com/apache/gravitino/pull/10182#issuecomment-3998290425
Hi @jerryshao, thanks for the question. Here's a concrete reproduction case: **Steps to reproduce:** ```bash # Start a Gravitino server, then send a null JSON body to the createTable endpoint: curl -X POST "http://localhost:8090/api/metalakes/my_metalake/catalogs/my_catalog/schemas/my_schema/tables"; \ -H "Content-Type: application/json" \ -H "Accept: application/vnd.gravitino.v1+json" \ -d "null" ``` When JAX-RS (Jersey) deserializes the literal JSON `null`, the `request` parameter becomes `null` in Java. The current code then does: ```java LOG.info("Received create table request: {}.{}.{}.{}", metalake, catalog, schema, request.getName()); // ^^^^^^^^^^^^^^^ NPE here try { ``` This happens **before** the `try/catch` block, so the NPE is not caught by `ExceptionHandlers` and the client gets an unhelpful HTTP 500 instead of a structured 400 Bad Request. You're right that normal Gravitino clients won't send `null` bodies, but this can happen with: - Direct REST API calls (curl, custom HTTP clients) - Malformed client implementations - Security scanning / fuzzing tools This is essentially a defensive programming improvement to ensure all REST endpoints return proper error responses at system boundaries, consistent with the existing `ExceptionHandlers` error handling pattern. -- 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]
