The createMetalake REST handler can crash with a NullPointerException when the request body is missing or deserializes to null. It logs request.getName() before validation and outside safe exception handling, so the endpoint fails with an internal error path instead of returning a controlled client error. This makes behavior inconsistent and hides a clear validation failure behind a server-side exception.
See gravitino/server/src/main/java/org/apache/gravitino/server/web/rest/MetalakeOperations.java around line 120.
Improve this by making null-safety the first step in the handler, and by reading request fields only after validation. Specifically, guard request up front, return a structured bad-request response when null/invalid, and keep logging and exception handling on safe values only.
Here's a unit test to help show the issue:
public class TestMetalakeOperationsNullRequest {
@Test
public void testCreateMetalakeWithNullRequestShouldNotThrow() {
MetalakeOperations operations = new MetalakeOperations(mock(MetalakeDispatcher.class));
assertDoesNotThrow(() -> operations.createMetalake(null));
}
}