apache/gravitino

What would you like to be improved? keep consistent with Lance community How should we improve? No response

What would you like to be improved? JobOperations has nine endpoints. Eight of them carry both @Timed and @ResponseMetered; cancelJob carries only @Timed: // server/src/main/java/org/apache/gravitino/server/web/rest/JobOperations.java:441 @POST @Path("runs/{jobId}") @Produces("application/vnd.gravitino.v1+json") @Timed(name = "cancel-job." + MetricNames.HTTP_PROCESS_DURATION, absolute = true) @AuthorizationExpression(expression = "METALAKE::OWNER || JOB::OWNER") public Response cancelJob( The Jersey listener registered by HttpServerMetricsSource creates response-class meters only for methods annotated with @ResponseMetered. Without it, gravitino-server.cancel-job.2xx-responses and the matching 4xx/5xx meters are never registered, so /metrics reports the latency of a cancel but never its outcome. A cancel that consistently fails with a 5xx increments nothing and is invisible to any dashboard or alert built on those meters, while every sibling endpoint in the same class reports its outco

Version main branch Describe what's wrong The create/register/add operations tracked by #12788 and addressed by #12791 do not cover all REST endpoints that require a request body. Several remaining operations still dereference a null request or invoke request.validate() without first rejecting a null body. An omitted or empty body, or a JSON literal null, therefore results in HTTP 500 instead of a structured HTTP 400 response. MetalakeOperations.setMetalake is a directly reproducible example. Source inspection found the same unguarded null-request pattern in the following operations, which should be validated and covered by regression tests when implementing the fix: BulkOperations removeUsers removeGroups CatalogOperations testConnection setCatalog MetalakeOperations setMetalake PolicyOperations setPolicy OwnerOperations setOwnerForObject PermissionOperations grantRolesToUser grantRolesToGroup revokeRolesFromUser revokeRolesFromGroup grantPrivilegeToRole revokePrivile

Version main branch Describe what's wrong Several create, register, and add REST operations call request.validate() without first rejecting a null request body. Null-safe name extraction only protects logging and error context; it does not protect the later request dereference. Affected operations include: Catalog, Schema, Table, Fileset, Topic, Policy, and Tag creation Function, Model, and JobTemplate registration User, Group, and Role creation Bulk user and group creation An empty or JSON null body should return a structured HTTP 400 response, but these operations currently return HTTP 500 after dereferencing the null request. Error message and/or stacktrace Expected: HTTP 400 Error code 1001 Error type IllegalArgumentException A message indicating that the request body cannot be null Actual: HTTP 500 An internal error response How to reproduce Send an authorized create-catalog request with a JSON null body: curl -i -X POST \ -H 'Content-Type: application/vnd.gravitino.v1+jso

What would you like to be improved? CatalogEventDispatcher currently delegates both pre-create and existing-catalog connection tests without emitting pre, success, or failure events. This prevents listeners and auditing integrations from observing these operations. How should we improve? Add event dispatching for all three testConnection overloads and cover their success and failure paths with unit tests. Follow the existing catalog event conventions for operation context and exceptions. Reuse the existing audit formatting and redaction behavior.