mchades opened a new issue, #12834:
URL: https://github.com/apache/gravitino/issues/12834
### 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`
- `revokePrivilegeFromRole`
- `overrideRolePrivileges`
- `MetadataObjectTagOperations`
- `associateTagsForObject`
- `associateTagValuesForObject`
- The deprecated `TagOperations.associateTagsForObject` route delegates to
the same implementation.
- `MetadataObjectPolicyOperations`
- `associatePoliciesForObject`
- `StatisticOperations`
- `dropStatistics`
- `updatePartitionStatistics`
- `dropPartitionStatistics`
Some operations extract a request field null-safely for logging or error
context but later dereference the same null request. Null-safe logging alone
does not prevent the HTTP 500 response.
### 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 caused by dereferencing the null request
### How to reproduce
Start the server from the main branch, create a metalake named `test`, and
send
an authorized request with a JSON `null` body:
```shell
curl -i -X PATCH \
-H 'Content-Type: application/vnd.gravitino.v1+json' \
-H 'Accept: application/vnd.gravitino.v1+json' \
--data 'null' \
'http://localhost:8090/api/metalakes/test'
```
`MetalakeOperations.setMetalake` dereferences `request.isInUse()` and returns
HTTP 500 instead of rejecting the missing request body with HTTP 400.
### Additional context
#12769 and #12770 fixed null-body handling for `createView`, equivalent alter
operations, and `linkModelVersion`.
#12788 and #12791 cover the listed create/register/add operations and are
intentionally excluded from this issue.
#10171 and #10182 already track `JobOperations.runJob` together with several
older create/register cases. `runJob` is therefore also excluded here.
The required behavior should be consistent for every endpoint that requires a
request body. The implementation may use centralized request-entity
validation
or operation-level guards, provided that:
- Null request bodies return a structured HTTP 400 response.
- Each affected operation has regression coverage.
- Existing malformed-JSON handling remains unchanged.
--
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]
