SARAMALI15792 commented on PR #10635: URL: https://github.com/apache/gravitino/pull/10635#issuecomment-4276036556
Fixed the failing `testInvalidMetadataObjectType` test. ## Root Cause The previous fix only validated `metadataObjectType` in the authorization interceptor path (`ParameterUtil` + `GravitinoInterceptionService`). However, REST unit tests bypass the interceptor and call the endpoint methods directly. This meant `MetadataObjectTagOperations` was still calling `MetadataObject.Type.valueOf()` directly at three locations (lines 113, 181, 273), which throws the JVM's default message: `"No enum constant ...Type.INVALID_TYPE"`. The test expected the message to contain `"Invalid metadata object type"`, so it failed. ## Solution Extracted a shared `MetadataObjectUtil.parseType(String)` helper that: - Wraps `valueOf()` in try-catch - Throws descriptive `IllegalArgumentException` with all valid types listed - Dynamically sources valid types from the enum (stays in sync with future additions) Updated all four call sites: - `MetadataObjectTagOperations.getTagForObject` (line 113) - `MetadataObjectTagOperations.listTagsForMetadataObject` (line 181) - `MetadataObjectTagOperations.associateTagsForObject` (line 273) - `ParameterUtil.extractNameIdentifierFromParameters` (line 87) Both code paths (interceptor + direct endpoint) now return HTTP 400 with the descriptive message. ## Testing ✅ `testInvalidMetadataObjectType` now passes ✅ Full `TestMetadataObjectTagOperations` test class passes ✅ No regressions Commit: e88a342e31e68a65b7031b7c3839dd3ab9d72646 -- 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]
