[#13216] fix(api): fix RemoveMetadataObject.equals ClassCastException and compare locations - #13219
Merged
jerryshao merged 2 commits intoSep 20, 2026
Conversation
…are locations RemoveMetadataObject.equals cast its argument to the sibling class RenameMetadataObject after the getClass() guard, so comparing two RemoveMetadataObject instances (including HashSet/contains) always threw ClassCastException. It also ignored locations, diverging from the sibling RenameMetadataObject.equals. Cast to RemoveMetadataObject, compare metadataObject and locations, and include locations in hashCode to keep the equals/hashCode contract. Repro TestMetadataObjectChange failed with ClassCastException on the unfixed tree; passes after the fix. Found by find-issues sweep.
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Handle null locations safely in equality and add regression coverage.
Get a fresh assessment by requesting another Copilot review.
Pull request overview
Fixes RemoveMetadataObject.equals/hashCode and adds regression coverage.
Changes:
- Corrects the equality cast and includes locations.
- Adds equality and
HashSettests.
File summaries
| File | Summary |
|---|---|
api/src/main/java/org/apache/gravitino/authorization/MetadataObjectChange.java |
Updates removal-change equality and hashing. |
api/src/test/java/org/apache/gravitino/authorization/TestMetadataObjectChange.java |
Adds regression coverage. |
Review details
Suppressed comments (1)
api/src/main/java/org/apache/gravitino/authorization/MetadataObjectChange.java:204
- Now that
locationsparticipates inhashCode, retaining the caller's mutable list makes theHashSetbehavior tested here unstable: mutating the list passed toremove(or exposed bygetLocations()) after insertion changes the hash, socontains/removecan no longer find the entry.RenameMetadataObjectdefensively copies its locations; apply equivalent defensive/immutable handling to this value before using it as a hash key.
return Objects.hash(metadataObject, locations);
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| RenameMetadataObject that = (RenameMetadataObject) o; | ||
| return metadataObject.equals(that.metadataObject); | ||
| RemoveMetadataObject that = (RemoveMetadataObject) o; | ||
| return metadataObject.equals(that.metadataObject) && locations.equals(that.locations); |
Address review on the equals/hashCode fix: compare locations with Objects.equals so a null locations (constructible via remove(obj, null)) does not NPE, and store an ImmutableList copy so the locations field — now part of hashCode — is a stable hash key the caller cannot mutate after construction.
Contributor
Author
|
Both points are valid and are addressed in 946bd50:
Added regression tests for both: equality with null |
Code Coverage Report
Files
|
jerryshao
approved these changes
Sep 20, 2026
Contributor
Author
|
Thank you @jerryshao |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
RemoveMetadataObject.equalsnow casts toRemoveMetadataObjectand comparesmetadataObjectandlocationswithObjects.equals, andhashCodeincludeslocations. The constructor stores anImmutableListcopy oflocations, so the value object is immutable and its hash key stays stable even if the caller later mutates the list it passed in.Why are the changes needed?
After the
getClass()guard the argument was cast to the siblingRenameMetadataObject, so comparing twoRemoveMetadataObjectinstances (includingHashSet/contains) always threwClassCastException, andlocationswas ignored. Comparing withObjects.equalsalso avoids aNullPointerExceptionwhenlocationsis null (constructible viaremove(obj, null)), and the defensive copy keepslocationsa stable hash key now that it participates inhashCode.Fix: #13216
Does this PR introduce any user-facing change?
No API change. Comparing two
RemoveMetadataObjectinstances no longer throwsClassCastException,equals/hashCodenow takelocationsinto account, and a builtRemoveMetadataObjectis immutable.How was this patch tested?
Added
TestMetadataObjectChange, which pinsequals/hashCodeforRemoveMetadataObject: comparing two instances andHashSetmembership (fails on the pre-fix tree withClassCastException), equality whenlocationsis null (fails pre-fix withNullPointerException), and that mutating the caller's list after construction does not change the object or itsHashSetmembership.